Handle restricted dependencies as implicit multiple-constraints dependencies

[radoering]

Pull Request Check List

Resolves: #5506

• Added tests for changed code.
• Updated documentation for changed code.

Although I think that this PR makes the solver more correct it comes with a massive performance regression that is far from acceptible.

I carried out some measurements with example pyproject.toml files from other PRs. If locking succeeds without this PR, the same lock file is generated with this PR, it just takes longer...

Times for poetry lock with a warm cache:

pyproject.toml from ...	time without PR	time with PR
#3367	0.8 s	2.8 s
#4670	1.8 s	4.2 s
#4870	71 s	11800 s (not a typo)
#5506	error after 4.5 s	1090 s
shootout example	3.9 s	250 s

Number of overrides:

pyproject.toml from ...	number of overrides without PR	number of overrides with PR
#3367	4	10
#4670	16	19
#4870	46	4179
#5506	-	288
shootout example	0	69

The data shows that the time seems to correlate with the number of overrides. Thus, I assume a more sophisticated algorithm to reduce the number of overrides or even a complete overhaul of how to handle multiple-constraints dependencies might be necessary. I can imagine to make the VersionSolver marker aware so that a version conflict is only a conflict if the intersection of markers is not empty. This way, overrides would not be necessary anymore and everything could be solved at once. However, that's probably a huge task.

[jeertmans]

Thanks for linking this to #8670 @radoering :-)

Maybe we should rewrite Poetry in Rust if speed is an issue ^^'

Jokes aside, having a resolving time this long is really an issue..