Performance: Short-circuit check based on pre-derived candidate Double

[ax1nch]

This is a minor performance improvement. A codeql query I ran over some library code had picked up on the empty catch blocks in this file. Those are already handled well here of course, but I happen to notice the allocating toStrings. Since the toString based checks were only used for this condition, I thought it might be nice to find a fully a numeric-only check here too, before following through the history of this, tickets like LANG-1018

So I then tweaked the check to work with a single toString. The performance improvement was consistent, but not significant enough to justify a change. However I feel the current simple shortcircuit check might be worth it - I mean it's almost a free check (like when false), but much faster as a replacement(when true) at ~100x (relevant jmh out below) . It also feels like an apt positive-test, given the fact that the candidate Double is already available at that point

.
Result "org.ex.NumericCheck.testDefaultCheck":
  84.675 ±(99.9%) 0.949 ns/op [Average]
  (min, avg, max) = (83.505, 84.675, 86.911), stdev = 0.888
  CI (99.9%): [83.726, 85.624] (assumes normal distribution)
.
Result "org.ex.NumericCheck.testNumericPreCheck":
  0.851 ±(99.9%) 0.024 ns/op [Average]
  (min, avg, max) = (0.817, 0.851, 0.897), stdev = 0.022
  CI (99.9%): [0.827, 0.875] (assumes normal distribution)
.
.
Benchmark                         Mode  Cnt   Score   Error  Units
NumericCheck.testDefaultCheck     avgt   15  84.675 ± 0.949  ns/op
NumericCheck.testNumericPreCheck  avgt   15   0.851 ± 0.024  ns/op

Also to note: the probability of a Float return may not be high in a random distribution of the param string but this is library code and so will be used in many cases where the distribution is not random, and there it counts