Add a command line option to select the resolver implementation

[pfmoore]

What's the problem this feature will solve?
When the new resolver is implemented, we will need to have a way to allow users to test it. One option is to add a new option to pip to allow selection of which resolver to use.

Describe the solution you'd like
Add a pip option --resolver=[legacy|new]. Name of the option and the values can be discussed. Choosing "legacy" will select the current resolver, choosing "new" will select the new resolver.

Notes:

• The default should initially be "legacy", so that the new resolver is opt-in. After a suitable period of testing, the default should change to "new".
• The option should be temporary, being removed along with the legacy resolver code once the new resolver is considered "final".
• Adding the option in advance of the new resolver code has been discussed - it's not yet clear what benefit this would have, but it is certainly possible.

Alternative Solutions
A boolean option like --enable-new-resolver could be used instead. The transition process might be more complex with such an option.

The new resolver could be made available simply as a separate feature branch of pip. This would make it significantly harder for users to try the new code, though.

Additional context
See Zulip for some additional discussion.

[uranusjr]

A few things to figure out:

• What commands should this be added to? install is the obvious one. wheel? What else?
• When should this be added? (In other words, when should we consider the new resolver user-testable quality?)
• Should there be only one, or multiple new resolvers? I know most of us want only one, but I kind of still think there should be a chance to compare base implementations in a wider scale. At least a direct comparison between ResolveLib/Zazo and Mixology would be a good thing IMO.

[pradyunsg]

re commands: install, download and wheel, because they create a resolver instance + care about dependencies.

(I'll respond to the rest later)

[pradyunsg]

One other idea is to add a more general flag (ALA #5727) which could be useful for other things like transitioning how our --no-* flags look in configuration files, for consistency.

That way, we have a longer lasting "setup", which enables some discoverability and allows us to build upon the communication / user-expectation-setting work we do as part of this rollout in the future.