Prioritize forks based on upper bounds

[charliermarsh]

Summary

Given a fork like:

pylint < 3 ; sys_platform == 'darwin'
pylint > 2 ; sys_platform != 'darwin'

Solving the top branch will typically yield a solution that also satisfies the bottom branch, due to maximum version selection (while the inverse isn't true).

To quote an example from the docs:

// If there's no difference, prioritize forks with upper bounds. We'd prefer to solve
// `numpy <= 2` before solving `numpy >= 1`, since the resolution produced by the former
// might work for the latter, but the inverse is unlikely to be true due to maximum
// version selection. (Selecting `numpy==2.0.0` would satisfy both forks, but selecting
// the latest `numpy` would not.)

Closes #4926 for now.

[charliermarsh]

Just a heuristic of course, and we don't really have a ton of examples to inform this work.

[konstin]

While this is an improvement, it does not fix the transformers example. Fork points for transformers:

• Splitting on pydantic==2.8.2 over typing-extensions
• Splitting on opencv-python==4.10.0.84 over numpy
• Splitting on pandas==2.2.2 over numpy
• Splitting on botocore==1.34.151 over urllib3

I think we need to prioritize based on python_version for that. I haven't dug in what part is missing yet.

[charliermarsh]

@konstin - Can you link to that example, and I'll explore it?

[konstin]

I'Ve added it in #5657

[charliermarsh]

Thanks! I'll merge this and then explore that separately.