freedreno/ir3: unmergedregs

Decouples MERGEDREGS vs split reg-file from gpu gen, so we can get rid of hacks about telling the hw that we aren't using MERGEDREGS when we are telling the compiler that we are.. (at a minimum, at least know we don't tell the hw that HALFREGFOOTPRINT is zero when it isn't)..

Compared to before, we are now using MERGEDREGS for both VS+GS when there is no HS/DS.. I'm reasonably sure that VS mergedregs and GS non-mergedregs is probably not right given the chsh stuff. But if there is HS/DS then VS/GS used !mergedregs mode.

I'm not entirely happy that we have completely figured this out yet.. it kinda seems like VS/GS should agree and half/full regfootprint (and maybe branchstack?). I won't rule out the possibility that not all the SP_xS_CTRL_REG0 have the same layout.

I am getting one vk CI regression, dEQP-VK.pipeline.multisample.min_sample_shading_disabled.min_1_0.samples_4.quad, which I've not looked into yet (so keeping this MR marked w/ WIP), but kinda seems like it should not be gs/tess related. Turns out turnip has it's own path to allocate ir3_shader_variants, so it was never getting mergedregs flag set. Fixed now. I'm a bit surprised about how little of vk CI broke because of that.

@brkho this might help unblock !5059 (merged)? (Either way, I'd prefer not to add more paper over the problem to just to get deqp tests to pass)

@anholt not sure if this was the only problem w/ 16b bools, but might be worth revisiting?

Probably would be worth getting @krh's shader replacement hacks into better shape so we could use those to confirm that the MERGEDREGS bits for GS/DS/HS actually mean what we think they do. I've confirmed with computerator that for compute shaders it actually means what we think it does. But I'm not ready to assume that all SP_xS_CTRL_REG0 have the same layout.