spirv-fuzz: transformation to swap (or add synonyms) for GLSL.std.450 instructions `FrexpStruct` vs. `Frexp` and `ModfStruct` vs. `Modf`

This transformation idea comes straight from the spec!

ModfStruct:

"Same semantics as in Modf, except that the entire result is in the instruction’s result..."

And the same for `FrexpStruct`.

The simplest case would be where we have a Modf (which glslangValidator still emits today):

```ini
%1 = OpExtInstImport "GLSL.std.450"
...
%struct_float_float_type = OpTypeStruct %float_32_type %float_32_type
...

%13 = OpExtInst %float_32 %1 Modf %float_in %float_variable_for_whole_num_output
```

The transformation would add:

```ini
%16 = OpExtInst %struct_float_float_type %1 ModfStruct %float_in
; Member 0 of %16 is synonymous with %13.

; The transformation could also add an OpLoad of %float_variable_for_whole_num_output
; and this would be synonymous with member 1 of %16.
```

* [SPIR-V spec](https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.pdf)
* [SPIR-V Extended instructions for GLSL (spec for Modf and ModfStruct)](https://www.khronos.org/registry/spir-v/specs/unified1/GLSL.std.450.pdf)

I think this should probably be a new transformation rather than adding to TransformationAddSynonym, so that we have the possibility of extending it to also add an OpLoad instruction (as explained above).

Start with the linked SPIR-V and GLSL.std.450 specifications and the Modf example in this issue. Determine the transformation's entry point and existing synonym transformations, then verify that Modf/Frexp and their Struct variants receive the intended synonymous results, including the optional OpLoad behavior.

Written by the indexing model from the issue text.