uv: update several dependencies in a single uv lock

[wenceslas-sanchez]

What are you trying to accomplish?

First half of #16390. LockFileUpdater only ever looked at the first dependency it was given: it rewrote one
pyproject requirement and passed one --upgrade-package to uv lock. This lets it take several dependencies and
run a single uv lock with one --upgrade-package per dependency, which is what we need to move packages that pin
each other (e.g. opentelemetry-api / opentelemetry-sdk) together.

There's a new upgrade_package_names: option so a caller can rewrite a requirement without forcing an upgrade of
that package. The follow-up PR uses it to relax a peer's pin and let uv move it only if it has to.

While here I fixed replace_dep matching a longer name that starts with the dependency name (boto3 vs
boto3-stubs), which multi-dependency updates make much easier to hit.

Anything you want to highlight for special attention from reviewers?

Apart from the replace_dep fix, there's no behaviour change for single-dependency updates: the command and
fingerprint are byte-for-byte the same, and the existing specs cover that. target_requirement still only applies
to the first dependency, the others are pinned to their own version. #13892 also touches run_update_command; happy to rebase on whichever lands first.

How will you know you've accomplished your goal?

New specs for the multi-dependency command and fingerprint, extras de-duplication, rewriting several pins,
and the boto3-stubs case. The full uv suite and rubocop pass locally. Sorbet reports no errors; I ran the
bundled sorbet binary with sorbet/config directly because bundle exec srb can't load the root Gemfile in
the uv dev image.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.