[ArPow] Create tarball generation and tarball build infrastructure for dotnet/installer

[dagood]

Once ArPow is complete through dotnet/installer, there's still work to do to generate the tarballs.

1. Infrastructure to clone the repos from dotnet/installer's Versions.Details.xml and put it in a tarball location. Following dotnet/source-build, this could be darc clone, but it would be nice to make it a lot simpler (and maybe faster) before then: Quality of life "darc clone --depth 0" improvements #1571
2. A full "strict coherent parent dependency" graph accessible in dotnet/installer, to put together a coherent set of repos. This just means we have to pick one version of each repo to work with--the build itself will probably not be fully coherent.
   • If it's not up to date, might need more work to fill it in, like [release/5.0.1xx] Add arcade-powered source-build strict coherent parent dependencies installer#8377.
   • Some work might be needed in the repos to flow this along: [ArPow] Add strict coherent parent dependency transitive graph to each repo to reduce dependencies #2017.
   • More info on "strict coherency": Yet another odd CPD scenario that needs resolution arcade#5195.
3. Infra to copy build tooling into the tarball to make it self-buildable.
   • May involve copying a chunk of dotnet/source-build release/5.0 infra into dotnet/installer eng/SourceBuildTarball/*.
   • There's a balance to make here. How much infra can be removed and replaced with ArPow's Arcade-side infra? Should we actually start using intermediate nupkgs in the tarball build as a way to safely segment up incremental builds (Add incremental builds by increasing isolation #928)?
4. Infra to publish the tarball as a public artifact from each official build. Note that we should be able to have one tarball serve all RIDs (The source-tarball genrated by source-build should work everywhere #1412, create linux-x64 compatible tarball for each release #298), but we can publish more tarballs if this doesn't end up working for 6.0.

This infra might make sense to permanently house in dotnet/installer's eng/ dir. dotnet/installer will be the only place producing tarballs for the foreseeable future, and having the code live in the repo directly rather than putting it in Arcade makes it significantly more maintainable when issues or new features come up.

To do an early prototype, we can choose a build subgraph and implement all of these steps there. (Any strict coherent parent dependencies are good incremental progress on other goals too (stage 4), and the bulk of the infra could probably just be moved to dotnet/installer when the full ArPow build graph is ready.)

[crummel]

Triage: @dseefeld to start proving this out after his 6.0 work.

[MichaelSimons]

Consider including #1694 as part of this work.

[dseefeld]

Completed with dotnet/installer#10961