Rework LLVM packaging

[ermo]

(originally reported by @ikeycode)

Currently our LLVM packaging is somewhat of a superpackage, and an absolute nightmare to maintain.

The proposal is to split into several individual packages within the
llvm namespace.

Goal

• Easier to maintain
• Trivial integration with boulder emul32 / PGO support.
• Support multiple LLVM versions (multiple toolchains require it)
• Not having to stay behind upstream due to one package.
• Update LLVM without bricking the split toolchain

llvm/llvm-libs

Simply contains the LLVM libraries, optimised as necessary. Required for
compat with all LLVM based toolchains. Initially we'll only ship a single
version of the LLVM libraries until virtual provider support is added to
permit shifting between the libs.

llvm15 == llvm, etc.
llvm14

llvm/clang

Provides the actual clang compiler, multilib capable. Again, the goal is to
eventually support multiple clang versions, decoupled from the libs.

Statically linked against llvm-libs

llvm/libcxx

Providing the libc++ libraries from LLVM.

Statically linked against llvm-libs

llvm/llvm-libgcc

Provide the libgcc shim to unfudge btrfs-progs, etc. This is due to our
use of glibc.

Statically linked against llvm-libs

llvm/lld

Separated linker. Follow latest clang/llvm. No multiversion

Statically linked against llvm-libs

llvm/ldb

Separated debugger. Follow latest clang/llvm. No multiversion

Statically linked against llvm-libs

Safety checklist:

• Ensure lld, clang et all are statically linked before proceeding with the split.

[ermo]

ermo
Is it known whether lld and ldb will work seamlessly between versions?

Does upstream have a policy on being backwards compatible or are we in "maybe it works with older toolchains? 🤷" territory?

Ikey Doherty
lld can work with, in theory, any ELF library. We'll statically link to newest llvm-libs.
ldb is a debugger and should just follow the same policy.