add support for package level conflicts with groups

[BurntSushi]

This PR adds support for declaring a conflict between a group
and a project's "production" dependencies. For example:

[project]
name = "example"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = [
    "anyio>=4.6.2.post1",
]

[dependency-groups]
foo = [
    "anyio<4.6.2.post1",
]

[tool.uv]
conflicts = [
  [
    { group = "foo" },
    { package = "example" },
  ],
]

Before this PR, syntax like { package = "example" } wasn't allowed.
This PR enables that syntax, and also tweaks the forking logic a bit
to support this.

I don't have 100% confidence in this PR. In particular, I'm not sure
if my trick adding a parent package to PubGrubDependency is fully
correct. But I think it works.

[zanieb]

(I think the experience makes sense, not feeling confident about reviewing the implementation)

[zanieb]

I've done a very dubious update with main.

[BurntSushi]

OK, I've pushed up a commit that I think gets this PR into working shape. There was a fair bit missing from UniversalMarker in sections that I think came after this PR was originally written. There was also a test asserting incorrect results (in the same way that the example in the PR description failed).

@BurntSushi does this also enable package <-> package conflicts? I'd expect that for workspace members. I think the use-case there is more important than package <-> group conflicts. (I can investigate this too, we'll want test coverage)

I think all the bones for this are there, but it doesn't seem to be fully working. Here's a simple concrete example. The root pyproject.toml:

[project]
name = "example"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = ["sortedcontainers==2.3.0"]

[tool.uv.workspace]
members = ["subexample"]

[tool.uv]
conflicts = [
  [
    { package = "example" },
    { package = "subexample" },
  ],
]

[build-system]
requires = ["setuptools>=42"]
build-backend = "setuptools.build_meta"

And now subexample/pyproject.toml:

[project]
name = "subexample"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = ["sortedcontainers==2.4.0"]

Without the conflicts declared here, this would normally fail to generate a lock file. But that part works and seems to generate a correct lock. But syncing fails (ignore the bad error messages for now):

$ run-uv -q pr1 -- sync
Resolved 4 packages in 5ms
error: The project and the project are incompatible with the declared conflicts: {the project, the project}

$ run-uv -q pr1 -- sync --package example
Resolved 4 packages in 3ms
error: The project and the project are incompatible with the declared conflicts: {the project, the project}

$ run-uv -q pr1 -- sync --package subexample
Resolved 4 packages in 6ms
error: The project and the project are incompatible with the declared conflicts: {the project, the project}

In order for these package level conflicts to work, there has to be way to sync only a specific package or set of packages.

[konstin]

(I'm still tagged here from the previous review, let me know if you want me to do another round)

[zanieb]

Thank you for addressing the problems!

there has to be way to sync only a specific package or set of packages.

We do already sync a subset, e.g., I don't think subexample would be installed there without --all-packages since it's not a dependency? I'll look into this.

[zanieb]

Just insta version churn / noise in this file.

[zanieb]

I'm going to move this to another pull request since it's got a pretty different scope now and it's a pain to keep looking up Andrew's PRs instead of my own :)

See #14906