AMDGPU: Libcall expand fast pow/powr/pown/rootn for float case (#180553)

This is to eliminate the special case global unsafe math options
in these functions from the library. The core operation only
uses about 4 instructions, and then there's an additional prolog
and/or epilog to fixup special cases.

I have an alternative patch which implements this by using separate
entrypoints in the library, and having the pass replace the calls
instead of this full handling. However, given the unfortunate state
of library development, it requires a full year to make cross project
changes. This is the most expedient path to deleting the control
library;
in the future we can do libcall emission when compiler has the real
ability to properly emit new calls.

This is mostly a direct port of these functions:

https://github.com/ROCm/llvm-project/blob/amd-staging/amd/device-libs/ocml/src/powF_base.h

I used copilot to do the heavy lifting on the drudgery of writing out
all the IRBuilder calls. It mostly worked, though it made mistakes in
porting != (used the ONE instead of UNE), plus some API usage errors.

The exact output isn't exactly the same. The ordering of some
instructions is different and some conditions and selects are inverted. 
This expansion also preserves the flags, so the finite only case optimizes 
better than with the library code (this is largely because fast math flags aren't
propagated yet, except for the few places SimplifyDemandedFPClass is called).

Alive2 verifies the library function with the special fast math path
functions have the same behavior as the result of this expansion. afn
only case: https://alive2.llvm.org/ce/z/uoPBC2

I did not bother trying to specially optimize the finite only cases
here. They get cleaned up by instcombine anyway, so doing so would only
be a hypothetical compile time improvement for a lot of additional complexity.
The exception would be existing, overlapped code in the pass. There's some 
overlap here with existing code in the pass. The afn+ninf+nnan case for powr
already does the rewrite to the 4 instruction core sequence, which takes precedence 
over this. In the future this should be merged, but it's more annoying now since the 
old path also handles it for the f64 case via libcall emission since the  intrinsic won't 
work.