This has the peek output include the fingerprint of the sources referenced in a target. This is a step towards #8445, by putting more information into peek.

For instance, with this, one way to get a crude "hash" of a target would be something like:

{ 
   pants dependencies --transitive --closed path/to:target | xargs pants peek
   # these might change behaviour and so need to be included
   cat pants.toml
   cat 3rdparty/python/default.lock # or whatever other lock files are relevant
} | openssl sha256

This is conservative: the hash can be different without the behaviour of the target changing at all. For instance:

• irrelevant changes in pants.toml: adjusting comments, unrelated subsystem config (e.g. settings in [golang] when path/to:target is a Python-only pex_binary)
• upgrading 3rd party dependencies in the resolve that aren't (transitively) used by path/to:target. This relates to --dependencies-transitive doesn't list third-party transitive dependencies #12733: if all transitive 3rd party deps appeared in pants dependencies --transitive, and pants peek included the right info for them (e.g. version and fingerprints), the cat 3rdparty/... could be removed because the peek pipe would handle it.
• target fields that don't impact execution behaviour, e.g. changing the skip_black setting on a python_source target, without changing the file contents (this might be most fields on the (transitive) dependencies of a packageable target?)

This is also only the hash of the input configuration, rather than a hash of a built artefact. If there's processes that aren't deterministic (e.g. shell_command(command="date > output.txt", output_files=["output.txt"]) somewhere in the chain), the exact output artefact might be different if built twice, even if the hash hasn't changed.

This PR is, in some sense, a partial revival of #8450, although is much simpler, because the JSON-outputting peek target already exists, and this doesn't try to solve the full problem.