Consider dropping bfloat16 demotion pass

[giordano]

If I'm interpreting llvm/llvm-project#97975 (comment) correctly, LLVM's problematic excess precision handling might not be in use with bfloat. If we can verify this, maybe we can just get rid of the demote pass for BFloat16 and have_bf16.

The other condition is that all our targets that do not support bfloat (i.e., most of them) properly legalize bfloat instructions to something that they do support. IIRC I encountered some instruction selection failures when first working on this, but those might have been fixed now that we're on a more recent version of LLVM.

Originally posted by @maleadt in #55417 (comment)

[maleadt]

Here's a test script: https://godbolt.org/z/bxa5f9r8P

Looking at Float16 on x86_64:

• up until LLVM 10, operations are incorrectly performed in excessive precision doing mul + mul + add without conversions in between
• starting with LLVM 11, there's conversions surrounding every mul and add

For BFloat16:

• up until LLVM 15, same thing as for Float16 (excessive precision)
• starting with LLVM 16, everything seems OK

Given the list of affected targets on llvm/llvm-project#97975, we can probably disable the demote pass altogether, except for PPC where we need to still demote Float16 (https://godbolt.org/z/7eKs6ErvG). Since AVR is also affected, it might be interesting to keep the pass available for AVRCompiler.jl.