Runtime intrinsics: fix fpext and fptrunc behaviour on Float16/BFloat16

[xal-0]

This makes two changes fpext and fptrunc to match the behaviour specified in their error strings:
-fpext works when converting from Float16 => Float16,
-fptrunc is prevented from truncating Float16 => Float16

Both are re-written to make it explicit what conversions are possible, and how they are done.

Closes #57130.

[xal-0]

I'm still not sure what the right thing to do is when doing fpext/fptrunc to/from BFloat16. Currently, it is allowed when "output bits >= input bits" holds for fpext, and when "input bits < output bits" for fptrunc. This has the weird effect of losing information on fpext:

julia> using .Core.Intrinsics
julia> using .Core: BFloat16
julia> fpext(Float16, fpext(BFloat16, Float16(12.3)))
Float16(12.31)

[oscardssmith]

I believe the correct behavior would be for fpext to allow going from Float16 or Bfloat16 to Float32/Float64 but not from Float16 to BFloat16 (or from Bfloat16 to Float16). I think that fpext is supposed to only allow transitions from src to dest if all possible src values are losslessly encodable in dest.

See also https://discourse.llvm.org/t/converting-between-different-but-same-sized-floating-point-types/59538 which suggests that there might not be any general understanding of what should happen here.

[xal-0]

LLVM seems to prohibit fpext and fptrunc with input size = output size:

llc: error: llc: fpstuff.ll:2:14: error: invalid cast opcode for cast from 'float' to 'float'
  %y = fpext float %x to float
             ^

llc: error: llc: fpstuff.ll:70:16: error: invalid cast opcode for cast from 'half' to 'bfloat'
  %y = fptrunc half %x to bfloat
               ^

llc: error: llc: fpstuff.ll:75:14: error: invalid cast opcode for cast from 'half' to 'bfloat'
  %y = fpext half %x to bfloat
             ^

[maleadt]

LGTM (superficially at least, it's been a while since I looked at this code).

For BFloat16s.jl it'd be fine to reject fpext/fptrunc between f16 and bf16, it currently should go through f32 anyway.

[vtjnash]

Since you are changing the permitted combination of behaviors, you will also need to update Compiler/src/tfuncs.jl and src/intrinsics.cpp to match these new rules, so that they all agree on exactly which errors are thrown and for what cases they can occur

[xal-0]

I decided to leave the incorrect handling of NaNs for later, since what to do is not entirely clear (#49353).