Cranelift: make authoring a new machine backend simpler, and document it

[cfallin]

Currently, adding a new backend to Cranelift entails at least the following:

• Defining an "assembler library" centered on a new MachInst type, with all the tedious and error-prone work around that (see Cranelift: generate more from declarative MachInst definitions #4125);
• Defining the register set;
• Defining glue constructors in ISLE to generate these instructions;
• Defining lowering rules in ISLE;
• Implementing top-level driver logic for the ISLE backend;
• Implementing a bunch of miscellaneous traits and types, such as the LabelUse relocation framework;
• Implementing an ABI binding;
• Implementing unwind info and debuginfo specifics for this platform;
• implementing whatever is necessary in the Cranelift embedder (e.g. for wasmtime, at least the fiber support, trap handling details, and object-file details like relocations).

While some of this is unavoidable, we should strive as much as possible to factor out the commonalities, and centralize things otherwise, and write documentation walking through the whole process.

In particular:

• Solving Cranelift: generate more from declarative MachInst definitions #4125 would allow the backend author to follow a declarative approach to sketch the instruction format, then "chase the type errors" to fill out the emission details, without too much fear of mistakes in the glue;
• Generating ISLE constructors for the machine instructions automatically would help a lot;
• Providing "default implementations" for a lot of the MachBackend trait, and factoring out the rest into smaller traits, would eliminate a lot of the duplication that currently exists.