agx: Stop bit-inexact conversion propagation

Despite being mathematically equivalent, the following code sequences are not bit-identical under IEEE 754 rules due to differing internal precision:

   fadd16 r0l, r0, 0.0              z = f2f16 x
   fadd16 r1h, r0l, r0h             w = fadd z, y

versus

   fadd32 r1h, r0, r0h              f2f16(w) = fadd x, f2f32(y)

This is probably fine under GL's relaxed floating point precision rules, but it's definitely not ok with the more strict OpenCL or Vulkan. It also is a potential problem with GL invariance rules, if we get different results for the same shader depending whether we did a monolithic compile or a fast link. The place for doing inexact transformations is NIR, when we have the information available to do so correctly. By the time we get to the backend, everything we do needs to be bit-exact to preserve sanity.

Fixes dEQP-GLES2.functional.shaders.algorithm.rgb_to_hsl_vertex. We believe that this is a CTS bug, but it's a useful one since it uncovered a serious driver bug that would bite us in the much less friendly Vulkan (or god forbid OpenCL) CTS later. It also seems like a magnet for GL app bugs, the fp16 support we do now is uncovering bad enough bugs as it is.

shader-db results are pretty abysmal, though :|

total instructions in shared programs: 1537964 -> 1571328 (2.17%)
instructions in affected programs: 670231 -> 703595 (4.98%)

total bytes in shared programs: 10533984 -> 10732316 (1.88%)
bytes in affected programs: 4662414 -> 4860746 (4.25%)

total halfregs in shared programs: 483448 -> 474541 (-1.84%)
halfregs in affected programs: 58867 -> 49960 (-15.13%)