mysql/decimal: match MySQL whitespace handling in numeric text

[GrahamCampbell]

go/mysql/decimal.NewFromString differs from MySQL in two whitespace cases. In evalengine, the returned parse error is discarded in these conversions, so the partial value can become a silent wrong result.

Leading vertical tab and form feed

MySQL treats vertical tab (0x0b) and form feed (0x0c) as leading whitespace:

SELECT
  CAST(CONCAT(CHAR(11), '+1') AS DECIMAL(20,6)),
  CAST(CONCAT(CHAR(12), '-1') AS DECIMAL(20,6));
-- 1.000000, -1.000000

decimal.NewFromString("\v+1") and decimal.NewFromString("\f-1") currently return zero plus an error, which can surface through evalengine as 0.

Space or tab immediately after e

MySQL accepts a space or tab after the exponent marker and before the optional sign/digits:

SELECT
  CAST('1e +5' AS DECIMAL(20,6)),
  CAST('1e -5' AS DECIMAL(20,6));
-- 100000.000000, 0.000010

Vitess currently parses only the leading 1, returns an error, and can surface the partial value as 1.

The grammar boundary appears narrow: 1e+ 5 and 1 e+5 remain partial-value cases in MySQL, and whitespace after e appears limited to space and tab rather than every leading-whitespace byte.

NewFromString should recognize these MySQL-compatible spellings so evalengine produces the same numeric results.

Found while reviewing #20721.

[arthurschreiber]

I'll fix this in #20721.