Refactor of the llvm-tblgen source into:
- a "Basic" library, which contains the bare minimum utilities to build
`llvm-min-tablegen`
- a "Common" library which contains all of the helpers for TableGen
backends. Such helpers can be shared by more than one backend, and even
unit tested (e.g. CodeExpander is, maybe we can add more over time)

Fixes #80647

```
find llvm/utils/TableGen -iname "*.h" -o -iname "*.cpp" | xargs clang-format-16 -i
```

Split from #80847

In D146869 @arsenm pointed out that the constrained intrinsics aren't
getting the strictfp attribute by default. They should be since they are
required to have it anyway.

TableGen did not know about this attribute until now. This patch adds
strictfp to TableGen, and it uses it on all of the constrained intrinsics.

Differential Revision: https://reviews.llvm.org/D154991

Depends on D146915

Differential Revision: https://reviews.llvm.org/D145937

For now, I have introduced `llvm::tmp::getValueType(Rec)` as a copy from
`CodeGenTarget.cpp`. This will be removed in the near future, when
IntrinsicEmitter will not depend on MVT.

Differential Revision: https://reviews.llvm.org/D143844

The TableGen implementation was using a homegrown implementation of
FunctionModRefInfo. This switches it to use MemoryEffects instead.
This makes the code simpler, and will allow exposing the full
representational power of MemoryEffects in the future. Among other
things, this will allow us to map IntrHasSideEffects to an
inaccessiblemem readwrite, rather than just ignoring it entirely
in most cases.

To avoid layering issues, this moves the ModRef.h header from IR
to Support, so that it can be included in the TableGen layer.

Differential Revision: https://reviews.llvm.org/D137641

Currently attributes for intrinsics are emitted using the
ArrayRef<AttrKind> based constructor for AttributeLists. This works
out fine for simple enum attributes, but doesn't really generalize
to attributes that accept values. We're already doing something
awkward for alignment attributes, and I'd like to have a cleaner
solution to this with
https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579 in mind.

The new generation approach is to instead directly construct
Attributes, giving us access to the full generality of that
interface. To avoid significantly increasing the size of the
generated code, we now also deduplicate the attribute sets. The
code generated per unique AttributeList looks like this:

  case 204: {
    AS[0] = {1, getIntrinsicArgAttributeSet(C, 5)};
    AS[1] = {AttributeList::FunctionIndex, getIntrinsicFnAttributeSet(C, 10)};
    NumAttrs = 2;
    break;
  }

and then the helper functions contain something like

  case 5:
    return AttributeSet::get(C, {
      Attribute::get(C, Attribute::NoCapture),
    });

and

  case 10:
    return AttributeSet::get(C, {
      Attribute::get(C, Attribute::NoUnwind),
      Attribute::get(C, Attribute::ArgMemOnly),
    });

A casualty of this change is the intrin-properties.td test, as I
don't think that FileCheck allows matching this kind of output.

Differential Revision: https://reviews.llvm.org/D135679