feat: add ExpMaxLimit and ExpMinLimit to prevent OOM / DoS via huge exponents

[singhlovepreet9]

Description

This PR introduces global ExpMaxLimit and ExpMinLimit variables (defaulting to math.MaxInt32 and math.MinInt32 to preserve backward compatibility).

The Vulnerability

Currently, shopspring/decimal is vulnerable to Denial of Service (DoS) attacks via memory exhaustion and CPU starvation. If an attacker submits a JSON payload containing an extremely large scientific exponent (e.g., {"value": "1E2000000"}), NewFromString parses the exponent successfully into its int32 representation.

While parsing is fast, any subsequent operation that relies on expanding or comparing this value (e.g., .String(), .Add(), .Cmp()) forces the underlying math/big.Int to allocate huge amounts of memory and stall the CPU.
For example, parsing "1E1000000000" (an exponent of 1 billion) causes the allocation of a single big.Int containing $\approx 3.32$ billion bits, instantly consuming ~415 MB of RAM. A web server receiving just a few concurrent requests of this nature will rapidly exhaust memory and crash.

The Fix

This adds two exported global limits, decimal.ExpMaxLimit and decimal.ExpMinLimit, checking them inside NewFromString.
Users running web services can now opt-in to bounded exponent parsing (e.g., decimal.ExpMaxLimit = 100000) globally on initialization, preventing OOM panics at the unmarshaling boundary without requiring wrapper structs.