fix Issue 15316 - different NaN value in struct initializer

[MartinNowak]

• the fix to restore signaling NaNs after real->float/double conversions
  was only applied to e2ir but not in todt, leading to different NaN
  init values for floats fields in default initalized structs
• move precision conversion functions to CTFloat and handle SNAN case
• optimized gdc builts of dmd still loose SNANs way earlier when
  initializing RealExp with TargetReal.snan fixed in 0bbe753

[dlang-bot]

Fix	Bugzilla	Description
✗	15316	struct float fields not correctly initialised on x64

[WalterBright]

Auto-merge toggled on

[MartinNowak]

Changed to only a partial fix of Issue 15316. While now the object file only contains SNaNs, initialization assignment of the __initZ struct literal for some structs (e.g. struct S { float f; double d; }( involves x87 loads/stores that will convert SNaNs to QNaNs. Changing the backend to always use movss/movsd for those is out of scope for this PR.

Note that it mostly works for S s = S.init; b/c that gets converted to field-wise assignment in the frontend, while S s; (S s = _D3mod1S6__initZ;) gets converted to struct assignment in the backend.

[WalterBright]

Auto-merge toggled off until it passes so that it doesn't jug up the autotester.

[MartinNowak]

This seems like a hopeless endeavor, we have little control over the init code for the other backends (though they are unlikely to use x87, but other architectures might also silence SNaNs).
As noone seems to rely on this much, I'd say we should switch over to QNaNs by default (Walter brought up that SNaNs didn't work out well).