Using lockfiles for construct.yaml building, documentation, testing?

After going down the custom installer route a couple of times now, I've occasionally run into the problem where I (or someone else) has the installer, but no longer the build log, and have to resort to shenanigans to find out what exactly is in it without installing it (which can be hard without, say, a physical OSX box kicking around).

An approach, derived from some of these adventures:

- capture the base required environment specs as one/more `environment.yml`s
- uses these to generate per-product lockfiles
- previously through weird means, `conda-lock is more fun and easier now)
- use the lockfile to generate `construct.yaml` (via environment variable + jinja)
- the solver _still_ gets invoked, so... meh
- run `conda list --explicit` inside the as-installed product and compare the input/observed lockfiles for deviations
- has only _found_ something once or twice, and usually indicated a bad `.condarc` in a build environment
- include the lockfile in the release bundle, shasums file, etc.
- it's also not _that_ big of a file to include directly _in_ the installer, which has its own benefits vs `conda-meta/history`

Also: a recent rev of `setup-miniconda@v2` supports `installer-url: file://`, which means that the test jobs can be instantiated on a machine that hasn't been "polluted" with a base installer.

End game: I'd love a `constructor` flavor that, given the same lockfile and tooling version, generated _exactly_ the same output (sha256), but there's a lot of other stuff that would [need doing](https://github.com/conda/conda-build/issues/2140).

Any interest in this as a PR?