d3d12: Cross-stage shader linkage improvements

This series improves how the d3d12 driver does cross-stage shader linking. Some background:

In DXIL/DXBC, a cross-stage variable (a varying in gallium terminology) has a semantic (a string name and an index), a row, and a set of columns that it occupies. If a varying spans multiple rows, it does so in a rectangular manner, i.e. keeping the same columns in every row where it's present. Later rows are implicitly a new varying of the semantic (name, index + row). D3D requires that between shader stages, if a variable is present for input, it must be present for output with the same semantic (name+index), row, and columns, except for system-generated inputs. That means that if (e.g.) a pixel shader wants to read SV_Position, it must put that variable at the same row where the pre-rasterizer stage put it. These variables must also be tightly packed in rows 0 - 32.

In gallium, a varying can have a location from 0 - 64, where the first 32 of these have special meanings and the latter are general-purpose (and another 32 for TCS/TES patch varyings).

This series addresses the following limitations that were present:

• Simplifying the shader keys for shader variants by removing a summarized list of varyings. The concept of that varying list remains for use in implicit GS/TCS shader keys.
• Improving runtime performance by removing dead varyings between shaders, instead of adding dead varyings to satisfy the linkage requirements. This also bumps the driver under some register limits that we were previously hitting.
• Preventing linking issues that arose due to link ordering. Previously we produced shader variants in forward pipeline order, and used the current variant of other stages for some linking/variant properties. Now, we only use properties that are variant-agnostic for computing shader keys.
• Stop creating a shader variant that's based on context state at the time of shader creation. This doesn't even mean anything. The "initial variant" was almost-never used anyway, so just defer creating a first variant until draw/dispatch time.
• Handle fractional varying locations for varying removal/sorting.

Altogether, this addresses #6570 (closed). It unfortunately doesn't address #10922 (closed).