Add automation for producing artifact slices.

[stellaraccident]

• Ship-ready artifact trees are output to artifacts/ using a common naming heuristic.
• These are generic artifact slices which split project groups into run/dev/dbg/doc subsets based on slice specific patterns.
• Artifacts can either be target neutral or target-locked, and this is represented in the name.
• The build system produces exploded artifact directories ready for upload/streaming via things like GH action artifacts or direct use in downstream processing.
• Like with systems such as Bazel, much care was taken on preserving convention and directory layout so that the pieces can all fit together systematically.
• The pseudo-target therock-artifacts produces all artifacts for the project. Individuals can be reached via targets like therock-artifact-base, therock-artifact-amd-llvm, therock-artifact-hipify.

This is a first step that just produces artifact slices for base/ and compiler/. Still a number of things todo:

• A future step will also produce archive files from these for direct installation.
• I want to add a diagnostic script which reports any duplication/ommissions so that patterns can be easily maintained.
• The build system will have a mode where it can initialize its build tree from an arbitrary set of artifacts from a prior build. This will disable configure/build steps for these pre-built parts and hardwire them to always uptodate.
• Populate the remaining directories (core, math-libs, ml-frameworks).
• Further tune LLVM's build/install configuration to reduce over-built assets at the source.
• Add global build system hooks so that debug symbol separation is done at build time (right now, all of the dbg slices are empty because the build system is either stripping or bundling debug info).
• Probably some additional tweaks needed for Windows specific patterns.

[stellaraccident]

FYI - sizes of artifact dirs right now (this is Release so no debug symbols):

406M    ./amd-llvm_any_run
4.0K    ./hipify_any_dev
439M    ./amd-llvm_any_dev
4.0K    ./hipify_any_doc
4.0K    ./amd-llvm_any_dbg
24K     ./amd-llvm_any_doc
49M     ./hipify_any_run
4.0K    ./hipify_any_dbg
3.5M    ./base_any_run
644K    ./base_any_dev
4.0K    ./base_any_dbg
28K     ./base_any_doc
160K    ./base_any_test
897M

I need to do some more surgery on the compiler:

• LLVM needs to be be packaged more fine grained so that it can have a run tree for things that just depend on the library (like hip) vs all of the tools. That will bring the part that needs to be distributed to support HIP down to ~160MiB or so (or much less given the next point).
• I think comgr needs some link tweaking too: it is much larger than I would expect (by 60MiB or so).
• hipify is not linking to shared libclang, so it is coming in about 40MiB heavier than it should.
• Sadly dynamic linking of this stuff doesn't work on Windows, so that'll just pay a large cost for the full toolchain. Will bias to cases that do not need the full toolchain being leaner.
• We're building too much of LLVM and the incantations I thought I knew on how to manage this defied my five minutes of trying to make it better. Need to refresh.

[ScottTodd]

For Windows support (#36), it would help to make some of these deps optional. For example, I don't expect rocm_smi_lib (or the successor project, https://github.com/ROCm/amdsmi) to compile on Windows.

[stellaraccident]

Yeah, we probably need some loose cmake to make some of them conditional as something like:

set(optional_artifact_deps)
if(NOT WIN32)
  list(APPEND optional_artifact_deps rocm_smi_lib)
endif()

...
  SUBPROJECT_DEPS
    ${optional_artifact_deps}

Could try to make it more automagical, but for this stuff, I generally prefer the readability of loose branchiness.