Handling of floating point environment

Most processors have a floating-point "environment" which includes the rounding mode, exception state, and probably other stuff.
C has a bunch of floating point environment-manipulation functions which expose that environment. LLVM has a bunch of pragmas, attributes, flags, and intrinsics which control what can be assumed about that environment, what optimizations are allowed, what can happen when various FP operations execute, and what instructions are selected.
Wasm actually [does not](https://webassembly.github.io/spec/core/exec/numerics.html#floating-point-operations) have such an environment; instead the rounding mode and exception behavior is fixed for all instructions (although there are a few instructions which have both trapping and nontrapping variants).
Emscripten has dummy implementations of [many](https://github.com/emscripten-core/emscripten/blob/master/system/lib/libc/musl/src/fenv/fenv.c) of those C functions, which do nothing because there is no environment to expose. Other than that, we don't do anything in particular in LLVM or clang to support or not support the various controls on modes or operations.

In general, we should
1) not crash when these various controls are used
2) correctly implement whatever controls can be implemented correctly
3) do something reasonable for controls that can't be implemented (an interesting question is whether to ignore them or throw some sort of error)
4) Take advantage of whatever properties wasm has to apply whatever optimizations are are possible.

In particular we are currently violating 1) (e.g. the `-frounding-math` causes LLVM's [constrained FP intrinsics](https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics) to be used, and we currently fail to lower the strict SETCC node during ISel dag legalization. The thing that caused me to write this up today was that upstream clang recently started supporting `#pragma STDC FENV_ACCESS ON` which is a per-function way to enable the same behavior, and that pragma is actually used by musl and causes build failures.
So in the very near term we need to at last either fix that ISel or comment those pragmas out of musl. Longer term we should figure out all the ways this functionality is exposed and what it should mean on wasm.