feat: default precision

[tomassasovsky]

This pull request introduces a new global configuration for controlling the default precision when converting infinite-precision rationals (such as 1/3) to Decimal. This allows users to specify how many fractional digits should be kept during such conversions, improving usability and preventing unexpected exceptions. The update includes new API fields, documentation, and tests for this feature.

New global configuration for infinite-precision rational conversion:

• Added static fields Decimal.defaultScaleOnInfinitePrecision and its alias Decimal.defaultPrecision to control the default number of fractional digits when converting infinite-precision rationals to Decimal. If unset, the previous throwing behavior is preserved.
• Updated RationalExt.toDecimal() to use the new global default if scaleOnInfinitePrecision is not provided for infinite-precision rationals. Throws an AssertionError if neither is set. [1] [2]

Documentation and usage examples:

• Added a new section to the README.md explaining the new default precision setting, with code samples and clarification of its behavior and scope.
• Updated CHANGELOG.md to document the new feature in version 3.3.0.

Testing and versioning:

• Added tests to ensure the new global default works as intended, including checks for correct behavior, error handling, and restoration of the original behavior when set to null.
• Bumped the package version to 3.3.0 in pubspec.yaml.

[a14n]

Thank you for the quality proposal - I appreciate the thoroughness of the work.

That said, I have some hesitations regarding the use of a global variable that might be accessed or modified by different libraries, potentially with conflicting values. I'm concerned this could lead to unexpected behavior or make debugging more difficult. Setting this value inside my code could potentially break a lib expecting another value (or an exception).

Also, could you clarify the purpose of having both defaultScaleOnInfinitePrecision and defaultPrecision as parameters? At first glance, it seems to make the API less intuitive. I'm wondering if there's a strong justification for keeping both, or if a simplification might be possible.

Looking forward to your insights.