uv-resolver: include conflict markers in fork markers

[BurntSushi]

When support for conflicting extras/groups was initially added, I
stopped short of including the conflict markers in uv's "fork markers"
in the lock file. That is, the fork markers are markers that indicate
the different splits uv took during resolution, which we record, I
believe, to avoid spurious updates to the lock file as a result of
using them as preferences.

One interesting result of omitting the conflict markers from the fork
markers is that sometimes this would result in duplicate markers. In
response, I wrote a function that stripped off the conflict markers and
deduplicated the remainder. My thinking at the time was that it wasn't
clear whether we needed to keep conflict markers around.

It looks like #10783 demonstrates a case where we do, seemingly, need
them. Namely, it's a case where after stripping conflict markers, you
don't end up with duplicate markers, but you do end up with overlapping
markers. Overlapping fork markers are bad juju for the same reason that
overlapping resolver forks are bad juju: you can end up with multiple
versions of the same package in the same environment.

I don't know how to fix overlapping markers without just including the
conflict markers. So that's what this PR does. Because of this, there
will be some churn in lock files, but this only applies to projects that
define conflicting extras.

This PR includes a regression test from #10783. I also manually tried
the original reproduction in #10772 (where adding numpy<2 caused uv sync to fail), and things worked.

Fixes #10772, Fixes #10783

[charliermarsh]

Could we possibly avoid this in some cases, even when conflicting extras are defined? Like, what if the markers aren't overlapping?

[BurntSushi]

Yeah I maybe I could modify this to collect only the PEP 508 markers and then only include the conflict portions if any of the PEP 508 markers are not disjoint with one another.

There's definitely another aspect of this which is whether the conflict markers are necessary to avoid the problems that resolution-markers were created to mitigate in the first place. But I'm pretty unsure about that.

[charliermarsh]

I would be curious if that change reduces the churn at all!

[BurntSushi]

Yeah it definitely reduces churn! It looks like we did have one existing test case that had overlapping markers (but was very easy to miss) that is also fixed too.