readFloat: memory exhaustion with large exponent

Summary

# `readFloat`: memory exhaustion with large exponent

`Numeric.readFloat` takes time and memory linear in the size of the number _denoted_ by the input string. In particular, processing a number expressed in scientific notation with a very large exponent could cause a denial of service. The slowdown is observable on a modern machine running GHC 9.4.4:

``` ghci> import qualified Numeric ghci> Numeric.readFloat "1e1000000" -- near instantaneous [(Infinity,"")] ghci> Numeric.readFloat "1e10000000" -- perceptible pause [(Infinity,"")] ghci> Numeric.readFloat "1e100000000" -- ~ 3 seconds [(Infinity,"")] ghci> Numeric.readFloat "1e1000000000" -- ~ 35 seconds [(Infinity,"")] ```

## In *base*

`Numeric.readFloat` is defined for all `RealFrac a => a`:

```haskell readFloat :: RealFrac a => ReadS a ```

The `RealFrac` type class does not express any bounds on the size of values representable in the types for which instances exist, so bounds checking is not possible (in this *generic* function). `readFloat` uses to `Text.Read.Lex.numberToRational` which, among other things, calculates `10 ^ exponent`, which seems to take linear time and memory.

**Mitigation:** use `read`. The `Read` instances for `Float` and `Double` perform bounds checks on the exponent, via `Text.Read.Lex.numberToRangedRational`.

## In *toml-reader*

The issue was detected in *toml-reader* version 0.1.0.0, and mitigated in version 0.2.0.0 by immediately returning `Infinity` when the exponent is large enough that there's no reason to process it.