Summarize package changes in uv sync json format output

[EliteTK]

Summary

Implement #16653 by making uv sync --output-format=json output information about package changes.

Test Plan

Additional tests to test the cases where there is no known package version may be beneficial but as the information used is the same as the information used by the dry run logging now, I don't think that's strictly necessary as those cases are tested.

[EliteTK]

So, to summarise a discussion from Discord, a suggestion was made to pull out the planning step from pip::operations::install into a separate plan function. Or, alternatively, just return the plan from install.

The goal being that a PackageChangeReport::from_plan can be added and used in the dry-run case, avoiding going through Changelog entirely, saving a bunch of code.

I've started to explore the idea of pulling out plan, but I don't think it's worth it. It adds a lot of boilerplate. I'll submit it as a separate PR and then I'll consider the alternative. Then whatever the result of that, this PR can be rebased on top and simplified.

[EliteTK]

So, the idea behind --dry-run is to produce output which is similar to what is produced without it, but without actually performing any actions. So, for example, the outputs below are almost identical:

$ uv sync
Resolved 6 packages in 2ms
Uninstalled 4 packages in 5ms
Installed 3 packages in 8ms
 - anyio==4.12.0
 + charset-normalizer==3.4.4
 - h11==0.16.0
 - httpcore==1.0.9
 - httpx==0.28.1
 + requests==2.32.5
 + urllib3==2.5.0
$ magically_revert_state # Trade secret
$ uv sync --dry-run
Would use project environment at: .venv
Resolved 6 packages in 1ms
Found up-to-date lockfile at: uv.lock
Would uninstall 4 packages
Would install 3 packages
 - anyio==4.12.0
 + charset-normalizer==3.4.4
 - h11==0.16.0
 - httpcore==1.0.9
 - httpx==0.28.1
 + requests==2.32.5
 + urllib3==2.5.0

And the goal of the json output is to present this information in JSON.

In the output above, the normal path uses InstallLogger::on_complete, but report_dry_run re-implements the code from DefaultInstallLogger::on_complete and kind of effectively produces the same information which would have been in Changelog. This¹ Changelog is only ever used to implement InstallLogger::on_complete logging, I think it actually would make sense for Changelog be the type which uniformly stores the information (regardless of whether it was from an install, or a dry-run install).

I think the only real changes which would be required is to: Expand the kinds of dists that Changelog can contain, so it can contain remote dists, and then adjust the respective ChangeEvent type (which similarly is only used within on_complete) to be able to deal with things without versions (possibly just fall back to a URL like the current report_dry_run code does). This would have the knock-on effect of allowing report_dry_run to just use the on_complete logger, cutting it down further.

Finally, report_dry_run can just return this Changelog type.

I believe this can all be done while keeping things pretty clean. Definitely no ZERO_VERSION hack ;).

Let me know what you think.

Footnotes

1. There are two Changelog types and two ChangeEvent types because of the slightly different requirements of where they are used. Both the logging functionality and the different changelogs could be unified, I think. But I don't think that it would necessarily benefit from being done now. I can kind of see it though, would be good to investigate one day, as there are two places where the DefaultInstallLogger::on_complete functionality is re-implemented verbatim. In fact, the changes suggested here would probably make such a change easier to implement. ↩

[zanieb]

Sounds fine to me!

[EliteTK]

Okay, rebased on top of the new changelog stuff, fixed the package naming and attaching the wrong lifetime to a reference in VersionOrUrlRef. This is ready I think?