Fixes fast_math attribute plumbing to llvm

[corleypc]

The (@fast_math) supplied flags get incorrectly passed to LLVM in lb_run_fast_float_math_pass(), because fast_math_flags is tested against ordinals instead of the corresponding bit positions.

Fixing it unmasks another issue. Some of the flags can't be applied to some of the LLVM instructions in the switch here, because they alias other flags. Here is a minimal example (for LLVMUIToFP) of reassoc aliasing nneg and turning unsigned conversions to signed conversions (build with -o:speed AFTER fixing the flags in lb_run_fast_float_math_pass(), otherwise it is essentially passing a random combination of flags):

package fast_math_test

import "core:fmt"
import "core:os"

@(fast_math={.Allow_Reassoc})
to_f64_fast :: proc(x: u64) -> f64 {
	return f64(x) // emits signed conversion because reassoc aliases nneg
}

main :: proc() {
	x := u64(0x8000_0000_0000_0000) + u64(len(os.args)) // runtime dependent so that conversion isn't optimized out
	fast := #force_no_inline to_f64_fast(x)

	fmt.printfln("reference: %f", f64(x))
	fmt.printfln("fast math: %f", fast)
}

To fix this, the commit replaces the explicit switch with a call to LLVMCanValueUseFastMathFlags() which should exclude conversions (and likely include a few other benefiting cases not in the switch) and should be more future proof.

All this is guarded by an LLVM version check in the commit, cause LLVM 17 doesn't seem to have support for fast math flags.