Enable Intel compiler back-end on Gen12.

This merge request implements support for the Gen12 (Tigerlake) ISA in the i965/Iris compiler back-end.

Gen12 is planned to include one of the most in-depth reworks of the Intel EU ISA since the original i965. The encoding of almost every instruction field, hardware opcode and register type needs to be updated in this merge request. But probably the most invasive change is the removal of the register scoreboard logic from the hardware, which means that the EU will no longer guarantee data coherency between register reads and writes, and will require the compiler to synchronize dependent instructions anytime there is a potential data hazard -- For the most part this is achieved transparently in a lowering pass (see "intel/fs/gen12: Introduce software scoreboard lowering pass.") that performs global dataflow analysis of the program, identifying dependent instructions and inserting the correct scheduling annotations or SYNC instructions in order to provide behavior equivalent to previous generations at the i965 IR level.

Unfortunately that's not sufficient because there is an amount of assembly code emitted manually by the code generation pass which had to be audited and fixed up by hand. Reviewers are encouraged to review these changes with special care ("intel/eu/gen12: Set SWSB annotations in hand-crafted assembly."), since the symptoms of broken synchronization annotations may be subtle and non-deterministic data corruption.

This merge request only includes the most critical changes to get the i965 back-end up and running on Gen12. Some performance and debugging features are still missing, including the changes required for the instruction compaction pass to handle the new ISA (@mattst88, do you feel like getting your patches for this ready for review?), assembler support (@sagarghuge, would you like to take care of this?), some optimization changes I have coming up based on the more accurate representation of the CFG introduced in this series (These used to be required in order to avoid shader-db regressions from this series, but I just verified they are no longer strictly necessary -- They still seem to help a few shaders though so I'll probably send them for review later on), a more optimal SBID allocation algorithm for the software scoreboard pass (I'll be taking care of the last two items).