1. LLVM doesn't release a full set of binary drops, so we need to
build llvm-tblgen on some platforms, namely Mac.
2. Build using standard CBL-Mariner Docker containers (used by
dotnet/runtime as well). This also converts linux-x64 builds to be
container-based cross builds.

Also, fix one compilation bug to build coredistools.cpp
with LLVM 16.0.1.

Build llvm-tblgen from source on Mac

It still doesn't build correctly.

Add options to scripts for non-CBL-Mariner builds.

Revert coredistools.yml to building using non-CBL-Mariner (the
CBL-Mariner logic is commented out). This means bringing back
the native (non-cross) linux-x64 build.

This wasn't done before, so it's no clear why it's needed now.

Also, it seems like the built llvm-tblgen isn't working.

Otherwise, we end up with clang-14 library dependencies in tblgen
that don't run on our arm cross-compiler Docker images.

20.04 has clang 10, not clang 9.

1. Disable annoying warning message
2. Set proper CMAKE linker flags for library creation

Use `tdnf install -y ncurses-compat` to install libtinfo.so.5
dependency of llvm-tblgen.

Even if we're building a shared library, we still need to set the
cmake EXE linker flags since cmake uses it during its testing phase.

To use this in dotnet/runtime, after the package is published,
`MicrosoftNETCoreCoreDisToolsVersion` in eng/Versions.props needs
to be updated.

Output more diagnostics on Linux build-coredistools build

Update documentation for building Linux

The matrix appends the architecture to the displayName automatically.

Remove some debugging output.

In desperation

1. Update header file to have type definitions for all DLL exported
functions.
2. Remove unnecessary x86 instruction prefix handling (it was
working around a bug that is apparently fixed).
3. Remove coredistools special handling of movw/movt. Instead, add
a hopefully more general mechanism where cordistools will optionally
first call a "munger" function on constants. This callback in the
superpmi NearDiffer for arm32 will decode the movw/movt and treat
the constructed constant as being generated by one instruction.
This can also be used by arm64 mov/movk/movk/movk, although we currently
don't have a need for that.

Looks like at least `lock` is still not treated as part of the instruction
that follows it.