The previous handling conflated RelPatchID and PrimID, which would
result in incorrect gl_PrimitiveID when doing draw splitting and didn't
work with PrimID passthrough which fills the VPC slot with the "correct"
PrimID value from the tess factor BO which we left 0. Replace PrimID in
the tess lowering pass with a new RelPatchID sysval, and relace PrimID
with RelPatchID in the VS input code in turnip/freedreno at the same
time so that there is no net change in the tess lowering code. However,
now we have to add new mechanisms for getting the user-level PrimID:

- In the TCS it comes from the VS, just like gl_PrimitiveIDIn in the GS.
  This means we have to add another register to our VS->TCS ABI. I
  decided to put PrimID in r0.z, after the TCS header and RelPatchID,
  because it might not be read in the TCS.
- If any stage after the TCS uses PrimID, the TCS stores it in the first
  dword of the tess factor BO, and it is read by the fixed-function
  tessellator and accessed in the TES via the newly-uncovered DSPRIMID
  field. If we have tess and GS, the TES passes this value through to
  the GS in the same way as the VS does. PrimID passthrough for reading
  it in the FS when there's tess but no GS also "just works" once we
  start storing it in the TCS. In particular this fixes
  dEQP-VK.pipeline.misc.primitive_id_from_tess which tests exactly that.

Part-of: <mesa/mesa!12166>