[red-knot] Allow multiple site-packages search paths

[AlexWaygood]

Summary

If a virtual environment's pyvenv.cfg file contains the line include-system-site-packages = true, anything installed in the system Python installation's site-packages directory will be accessible when the virtual environment is activated, as well as anything inside the virtual environment's site-packages directory. That means that we could have 0, 1, or many site-packages directories that we'd need to consider as search paths -- currently we only contemplate the 0 or 1 possibilities. As such, it makes sense for the site_packages field on Program to be a Vec rather than an Option. This is the first commit of this PR.

The second commit of the PR updates some of the logic in the resolver to reflect the fact that if there are two site-packages directories on sys.path at runtime, any editable installs provided via .pth files in the first site-packages directory will take precedence over the second site-packages directory when it comes to module resolution.

Test plan

cargo test

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

Okay, I'll wait with reviewing then

[AlexWaygood]

I added a test and updated the PR description. Ready for re-review!

[MichaReiser]

I do think that moving site packages constructing into the dynamic modules query will make it harder for validation but whatever. Let's ignore this for now

[AlexWaygood]

Yeah, @carljm was wondering if all this lazy .pth-file iteration was a bit too fancy -- we should maybe just collect all search paths eagerly. Definitely open to that; I have no idea how much lazy iteration through .pth files actually saves us.

[carljm]

I can't imagine lazy iteration of .pth files saves us anything at all in any realistic scenario. It would require that there is a site-packages path, with editables installed into it, that the project never actually imports anything from; all imports are first-party. So yeah, I'd favor simplifying by just collecting all search paths eagerly.