This changes it so that `cargo package` will make sure the Cargo.lock file is
in sync with the Cargo.toml that is generated during packaging. This has several
points:

- This makes the Cargo.lock more accurately reflect what would be locked
  if a user runs `cargo install` on the resulting package.
- In a workspace, this removes irrelevant packages from the lock file.
- This handles `[patch]` dependencies and dual-source dependencies (like
  path/version).
- Warnings are generated for any differences in the lock file compared to the
  original.

This has a significant change in how `cargo package` works. It now
unconditionally copies the package to `target/package`. Previously this was only
done during the verification step. This is necessary to run the resolver against
the new `Cargo.toml` that gets generated.

Requires `--locked` to use Cargo.lock for registry and git installs.

This only applies for `cargo package/publish` with the publish-lockfile feature,
or `cargo install --locked`.

The feature still needs to be enabled.

This constructs the new Cargo.lock in memory instead of writing it directly
to disk. The in-memory copy is added to the tar file directly.

Try to make it clearer that it is not modifying the actual Cargo.lock file, but
the one that is being stored in the .crate file.

This also restores the Cargo.lock update during packaging.

This was added for `cargo install` to avoid updating the source multiple times.
Now that multiple updates are guarded via `Config::updated_sources`, it is
no longer necessary.

This includes `Cargo.lock` in the git dirty check. It explicitly excludes
`Cargo.lock` as an untracked file, since it is not relevant for the dirty check;
it is only checked if it is committed to git.

This also adds `Cargo.lock` to the "did anything modify this" check during
verification. I don't see a reason to exclude it (particularly since ephemeral
workspaces do not save the lock file).

Also add "Archiving: Cargo.lock" to the verbose output.