GH-37730: [C#] throw OverflowException in DecimalUtility if fractionalPart is too large

[davidhcoe]

Rationale for this change

In BigQuery, the BIGNUMERIC supports very large precision and scale values, which causes an error in the DecimalUtility due to the fractionalPart of the value being larger than .NET's maximum decimal value.

What changes are included in this PR?

1. Throws an OverflowException with the entire original value
2. Changes the original OverflowException to also include the original value (which can be parsed as a string by downstream drivers).

Are these changes tested?

Yes, tests are added for this scenario.

Are there any user-facing changes?

• Closes: [C#] DecimalUtility fails with BigQuery's BigNumeric(76,38) #37730

[github-actions]

⚠️ GitHub issue #37730 has been automatically assigned in GitHub to PR creator.

[davidhcoe]

@lidavidm - can you help with this one too, please?

[lidavidm]

The test cases confused me, but looking at it, it's not necessarily about too big or too small, but rather too precise?

Arrow represents 7.89 in decimal256(76,38) as 789000000000000000000000000000000000000
integerPart is then 7
fractionalPart is 89000000000000000000000000000000000000
and that's just too many digits of precision for decimal?

Which, it is literally too big, but that's a bit confusing unless you are thinking about the representation.

[lidavidm]

Separately, I think it would be useful to differentiate the error messages here and possibly include the problematic value

[davidhcoe]

updated in latest push

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 5 benchmarking runs that have been run so far on merge-commit 629ecbd.

There was 1 benchmark result with an error:

• Commit Run on ec2-m5-4xlarge-us-east-2 at 2023-10-06 21:30:48Z
  • tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-15, scale_factor=10

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 7 possible false positives for unstable benchmarks that are known to sometimes produce them.