pan/bi: Rewrite the IR

The IR on master was designed before having canonical information about the hardware, and as such has a lot of quirks. The rework differs in these ways:

• Canonical opcodes, mapping down to the hardware forms (which are sized/typed) at NIR->BIR time instead of at pack time.
• IR models all the weird quirks of instruction modifiers so we don't need to keep churning to emit new instructions as we pipe in new functionality.
• Enums, printing, and packing generated from the XML directly.
• A competent builder! With proper support for composition and inline constants. "Cosmetic" but it makes NIR->BIR a lot neater, seen with the dramatic reduction in line count.
• Wider indices for sources. Instead of open coding everything, we use a proper data structure (64-bits instead of 32-bits to accommodate a 32-bit constant) which is easier to both produce and consume (meshes well with the builder).
• Streamlined swizzles. Instead of representing every possible combination of vec16 channel (a mess to work with, and costing 64 bytes of memory per instruction!), where almost everything is not encodeable, split out the 32-bit word offsets from the sub-word swizzles. The 32-bit word offsets are maintained in the index structure (with syntax sugar to help extract from vectors), and allowing a limited form of SSA combines in the backend.
• (Planned) Use-def chains. A lot of optimization passes (including the WIP marked copyprop pass here..) are accidentally O(N^2) due to missing metadata. With the new builder, it should be possible to track use/def (source/destination) metadata and knock these passes down to O(N).
• (Planned) FABS/FNEG/FSAT pseudoinstructions with propagation.

The MR is draft due to:

[x] Tests flaking with INSTR_INVALID_ENC. FIxed [x] Broken fp16, to be addressed with swizzles. [ ] Commit history is a non-bisectable mess, actually this is the cleaned up version...

Use-def and modifier work can follow after the merge.