Use run-time parsing to work around a compiler bug (#15923)

Due to SR-7124, some float literals are inconsistently handled
across architectures.  That's a problem for a test which is
trying to verify that certain exact floating-point values are
formatted in specific ways.

Fortunately, the run-time float parsing does not have this
problem, so I've changed this test to make sparing use of
run-time parsing (`Float("1.234")`) instead of compile-time
parsing (`1.234 as Float`).

This is admittedly slower, but the test isn't particularly
performance critical, and I don't want to use a hex literal
here since I feel that would make the test case harder to
understand.

Author: tbkka

test/stdlib/PrintFloat.swift.gyb

@@ -570,7 +570,10 @@ PrintTests.test("Printable_Float") {
   // closest to the midpoint between two binary floats
   expectDescription("7.0385313e-26", 7.0385313e-26 as Float)
   // Second-worst case for shortness:
-  expectDescription("7.038531e-26", 7.038531e-26 as Float)
+  expectDescription("7.038531e-26", Float("7.038531e-26")!)
+  // Note: The above test computes the reference value from a
+  // string because `7.038531e-26 as Float` is broken:
+  // See https://bugs.swift.org/browse/SR-7124
 
   // NaNs require special care in testing:
   // NaN is printed with additional detail to debugDescription, but not description