[fdcastel]

Fixes #1301.

Summary

INT128-backed NUMERIC/DECIMAL values are no longer converted to System.Decimal while the row is decoded. They are converted exactly instead, so a row can always be read, the connection stays usable, and nothing is rounded silently.

Changes

• TypeDecoder.DecodeInt128Numeric / BigDecimal.Create return a decimal when the value fits exactly, using the smallest scale. Otherwise they return an internal BigDecimal (an unscaled BigInteger plus a scale).
• Both clients use it: the managed reader (GdsStatement.ReadRawValue[Async]) and the native client (DbField.SetValue). The native client now also decodes NUMERIC(38, 0)/DECIMAL(38, 0) as numeric, consistent with GetFieldType() and with the managed client.
• For a value that does not fit decimal:
  • GetValue, GetDecimal and GetFieldValue<decimal> throw OverflowException, for that column only.
  • GetString returns the exact value, in the current culture like decimal.
  • GetDouble and GetFloat return the nearest value.
  • GetFieldValue<BigInteger> returns integral values exactly. This also works for values that fit decimal; fractional values throw OverflowException.
• DbValue.GetDecodedValue[Async]: the native client copies decoded values into the row without the conversion that GetValue performs.

Behavior changes (breaking)

1. Values with more than 28 fractional digits now throw instead of being rounded. For example, cast('1E-30' as numeric(38, 30)): master returned 0, now GetValue/GetDecimal throw OverflowException and GetString returns 0.000000000000000000000000000001.
2. Native client, NUMERIC(38, 0)/DECIMAL(38, 0). Master's GetValue returned BigInteger, now it returns decimal (as GetFieldType() always reported, and as the managed client always did). For values beyond decimal, GetValue now throws OverflowException; GetFieldValue<BigInteger> still returns them exactly.
3. Side effect: an integral decimal parameter value can now be passed to an INT128 parameter, because the same DbValue.GetInt128 serves both. It threw InvalidCastException before.

All other values decode exactly as before. I compared master's decoding with this one on 2,000,000 random values (1 to 38 digits, scale 0 to 38, seeded):

Outcome	Count
both decimal, identical value and scale	1,136,464
both decimal, different	0
master threw OverflowException; now exact	479,201
master returned a silently rounded decimal; now exact (change 1)	384,335
master returned the exact value, but now BigDecimal	0

The same comparison measured decoding time (Stopwatch, boxed like the row decoder; one machine):

Value	Master	This PR
22-digit NUMERIC(38,6)	164 ns	22 ns
1234.5	66 ns	50 ns
123 as NUMERIC(38,0)	2.5 ns	5.0 ns

Tests

• BigDecimalTests (NoServer):
  • exact/inexact boundaries: decimal.MaxValue ± 1, scale 28/29, trailing zeros,
  • formatting, including a non-invariant culture,
  • rounding and integral conversion.
• FbLongNumericsSupportTests:
  • values that fit decimal, including NUMERIC(38, 30) value 1 and NUMERIC(38, 0),
  • values that do not fit: the row is read, other columns are readable, GetString is exact, GetDouble is nearest, GetValue/GetDecimal throw, and the connection is still usable afterwards,
  • GetFieldValue<BigInteger>.
• Without the fix, 14 tests fail on the embedded client. With it, the embedded + NoServer suite passes: 648 passed, 0 failed.