Consider a secondary source of prebuilt artifacts

We ran into an issue of prebuilt clang binaries needing a too-new version of glibc, and that sparked me to build our own clang distribution from source. I made it fully statically linked to avoid glibc issues in the future. See https://github.com/dzbarsky/static-clang/tags

Another reason we did this is because the normal distributions are huge (700MB compressed 5.5GB uncompressed).

I'm planning to continue to tag point releases as they come out, since everything is automated and it's very low effort. @siddharthab Curious to hear what you think of this approach, if you're interested in making this a more-supported option in the toolchain, we can expand the built archive to include the rest of the tools that I've [currently stubbed out](https://github.com/dzbarsky/static-clang/blob/2ec5f47b5146b110ab131fb0e1981569fe3664b4/BUILD#L44-L49)

Review the static-clang tags and the referenced BUILD lines to understand the proposed artifacts and currently stubbed tools. Then inspect how this repository sources and packages LLVM toolchains. Done would require an agreed, supported secondary artifact source and a defined scope for the additional tools.

Written by the indexing model from the issue text.