build reproducibility features

This might become an eternal metabug bug I've gotta start somewhere!

So you want your build to be reproducible, or at least certain aspects of your build to be reproducible (while perhaps tweaking others). Some increasing levels of reproducibility I am vaguely aware of:

1. I can at all build the application reliably
2. A local developer can build the application reliably
3. I can produce a binary with the same general behaviour/characteristics
4. Perfect bit-level reproducibility is possible (may require a vm image)
5. Heurmetically sealed builds (all build/runtime deps precisely tracked)

For a "pure" rust application, levels 1 and 2 are pretty free. But if you have system deps you may find yourself needing something like #102 (linux build deps).

Level 3 is where cargo-dist can put in some "simple" extra elbow-grease:

* record toolchain info like cargo-dist version, rust version, maybe clang/xcode/visual-studio/etc info
* describe: store precise empirically observed information in the dist-manifest.json (may require #45)
* prescribe: allow the user to record what versions they want in their config so the CI can try to fetch those (cargo-dist-version=xxx, rust-version=xxx, ...)
* record exact compiler invocations cargo-dist performed to produce an artifact in dist-manifest.json
* timestamps..? system info dumps..?

Level 4 requires even more effort, I'm not sure if rust has a clean story on bit-level reproducibility:

* Probably just need docker
* Probably need binary sanitization steps like #32

Level 5 I think is basically just "use nix", and even then only nixos will really enforce that you eat your vegetables. It has some (experimental?) support on macos. It has no real support on windows (mingw/wsl don't count in my books, sorry).

-----------

Getting "level 3" rock-solid is all I *truly* care about, because I think it's important to be able to go back and do new builds for historical releases that work similar to the old ones but with potentially changed behaviours. For instance you might want to apply a bugfix, or bring up a new platform, update a problematic toolchain, get missing debuginfo, or bisect various build variables. In these cases level 4 and 5 aren't strictly applicable, but it would still be nice to preserve everything that can/should be the same.

That said I am absolutely happy to support going "deeper". It's just not my expertese and will probably need to be opt-in because I can't tell every windows dev to setup docker/nix to do a build. I want cargo-dist to be able to still do useful things if you're not a hardcore release engineer and just want "decent builds now".

Start by narrowing the issue to the level-3 reproducibility goals, especially toolchain information, compiler invocations, and dist-manifest.json. The issue names no implementation files or tests, so identify the relevant cargo-dist entry points and existing manifest behavior before proposing scope. Done should be defined by an agreed, testable reproducibility feature rather than the entire metabug.

Written by the indexing model from the issue text.