BigDecimal Precision/Scale Fix

[Jeffery-Wasty]

For operations with BigDecimal, precision and scale of 38 and 1 respectively (decimal(38,1)) are used, as opposed to the actual values for the object. This leads to loss of accuracy in transactions involving BigDecimal. This changes the param.typeDefinition to match the precision from the BigDecimal object. Four tests to confirm the fix for subtraction, addition, multiplication, and division operations are also present. This fixes issues 1489 and 942.

Parameter.java

• 535 - 540: Given a BigDecimal object, whose value is not null, and whose precision is larger than the present scale (default 1), assigns param.typeDefinition a precision based on the object, as opposed to the maximum value (38) previously used.

StatementTest.java

• 1483 - 1657: Tests confirming the fix works for operations involving subtraction, addition, multiplication, and division.

[Jeffery-Wasty]

I've applied the formatting change with tableName to other similar variables, where the only use case was AbstractSQLGenerator.escapeIdentifier. This can be rolled back if not appropriate for this PR.