Math library accuracy + performance improvements

[ecc521]

This corresponds to a 2019 PR that should have been merged a log time ago. It addresses two performance & accuracy issues in the previous scratch-vm repository that remain in this repository (2198 and 2199) .

scratch3_operators.js & math-util.js: Floating-point bounding for trigonometric operations (sin/cos/tan) was relying on parseFloat(..., 10). This is replaced with scaled floating-point arithmetic Math.round(... * 1e10) / 1e10. Operators are additionally bounded by % 360 to prevent IEEE-754 precision loss at large scale values.

• This is pretty much a no-brainer in my book. It's better math + performance improvements. The changes shouldn't break any existing projects since only large angles are affected here (the error doesn't exceed 0.01% until 66 trillion degrees).

cast.js: The Cast.isInt boundary check utilized parseInt(val, 10). For stringified values in scientific notation (e.g. 1e22), parseInt parsed out "1", erroneously evaluating the float as non-integer. Modulo constraint (val % 1 === 0) evaluates correctly without stringification. This change is practically irrelevant but technically a bug fix.

Verification
Unit parity with Scratch native tests verified (npm run tap:unit).
blocks_operators and blocks_operators_infinity tests fully pass, ensuring proper edge case constraints for non-standard numerics (NaN, Infinity, -0).

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[ecc521]

I have read the CLA Document and I hereby sign the CLA