intel/brw: Don't consider UNIFORM_PULL_CONSTANT_LOAD a send-from-GRF

It's a logical opcode which is lowered to a send-from-GRF later.  That
lowering code is responsible for ensuring the sources are set up in a
proper SEND payload.

This was preventing copy propagation of surface handles which started
out as scalars, were splatted out to full-SIMD values with NoMask, then
actually consumed as only component 0 (scalar again), because we thought
that scalar values were not allowed.

fossil-db on Alchemist shows improvements in q2rtx but no other titles:

   Totals:
   Instrs: 161310436 -> 161310152 (-0.00%)
   Cycles: 14370605159 -> 14370601066 (-0.00%)

   Totals from 17 (0.00% of 652298) affected shaders:
   Instrs: 16097 -> 15813 (-1.76%)
   Cycles: 185508 -> 181415 (-2.21%)

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28286>

src/intel/compiler/brw_fs.cpp

@@ -211,8 +211,6 @@ fs_inst::is_send_from_grf() const
    case SHADER_OPCODE_MEMORY_FENCE:
    case SHADER_OPCODE_BARRIER:
       return true;
-   case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD:
-      return src[1].file == VGRF;
    case FS_OPCODE_FB_READ:
       return src[0].file == VGRF;
    default: