Impact of Metal ffast-math on portability and CTS

Adding this issue to track and discuss the impact of Metal's `ffast-math` shader compilation option.

1. Enabling `ffast-math` enables [these performance optimizations](https://github.com/gpuweb/gpuweb/issues/2076#issuecomment-909613843) in the LLVM MSL compiler.

2. It is [known](https://github.com/KhronosGroup/MoltenVK/issues/1209) that disabling `ffast-math` has a significant negative impact on shader and game performance.

3. It is not yet clear yet how MSL, with our without `ffast-math` optimizations, behaves relative to SPIR-V's accuracy requirements.

4. MoltenVK [currently](https://github.com/KhronosGroup/MoltenVK/pull/1226) enables `ffast-math` optimizations by default when compiling MSL shaders, _**but**_ disables it for shaders that indicate `SignedZeroInfNanPreserve` execution mode.

5. Further MoltenVK testing via CTS will explore whether `ffast-math` should also disabled under other conditions indicated within the SPIR-V code (eg. `DontFlatten`, `DontUnroll`, etc).

Review the linked GPUWeb discussion, MoltenVK issue and pull request, then examine the CTS results for shaders compiled with and without Metal's ffast-math option. Determine which SPIR-V execution modes require disabling the optimization and document the CTS-backed portability decision.

Written by the indexing model from the issue text.