This started as a fixing a misalignment issue, but I got carried away.
Was originally 41 bytes (overflowing it's expected 40 bytes by 1 bit).

Now it's 27 bytes plus 8 bits of padding (ready for future expansion).

The savings come from:
 - Removing UV usage from components, it can be reconstructed from
   texcoord_elem_count (saved 8 bits)
 - Removed the 8 unused bits from texMtxInfo_n_projection (saved 8 bits)
 - Removing unused bit from from start of components (saved 1 bit)
 - Removed extra bit from inputform, texgentype and sourcerow
 - packed texMtxInfo_n_projection and texcoord_elem_count back into
   the per texgen info space freed up above. (saved 24 bits)
 - Overlayed postMtx index and Emboss mode shifts into a union based on
   texgentype (saved 56 bits)
 - Move to a single-bit union tag, freeing up an extra bit for regular
   texgens.
 - Move PotMtx normalize into the freed up space (saved 8 bits)

Total savings: 105 bits of data

EDIT: Even worse, MSVC wasn't respecting pack(1) for bitfields at all,
      so on windows this struct was actually quite a bit larger.
      Something like 80 bytes, if not more.

      Fixed this by dropping the size of any enums used in these
      bit structs to u8. Our Common::BitField allows for the underlying
      type to be explicitly specified to something larger.

      msvc's bitfield packing appears to be completely braindead, can't
      mix sizes at all.

We handle all six registers (scale/offset * xyz) via the viewport name.
Keeping around unused enumerators only for the z component is confusing.

See https://bugs.dolphin-emu.org/issues/13070.

At least in MSVC (which is not restricted from targetting C++20), these can be resolved to either std::format_to or fmt::format_to (though I'm not sure why the std one is available).  We want the latter.

fmt 8.0.0 requires this.