Support UntypedBigdecType, BigdecType, Float32Type and Float64Type.

[jaekwon]

UPDATE2:

Currently, BigdecType is almost arbitrary precision, except for hex_p notation (whatever it's called).
I don't understand how you can support numbers like 0x1p-53 without loss of precision, without some tricky system to manage precision across operations. Instead, it's supported to a precision of around 1024bits. Multiplication and division also have a precision of about 1024 digits. To be completely spec compatible, we might need to use big.Float or some other arbitrary precision library just to hold hex_p numbers, but I think it's better to keep it simple as is and just document the difference.

After this PR, it will become possible to upload the flowrate library with some simple modifications: (a) remove sync mutexes (for now, sync is not supported), and (b) remove time.Sleep() synchronous API.

---

UPDATE: if we don't need to worry about fusing *+, and if we panic upon NaN, and we don't use sin/cos etc, is there any nondeterminism at all? For now this PR just implements native operations. Meanwhile this article has a lot of references to cross check: https://gafferongames.com/post/floating_point_determinism/

Some insights:

• across architectures, different results for trancendental functions (sin, cos, tan, and their inverses).
• fusing depends on architecture and compiler.
• https://groups.google.com/g/golang-nuts/c/PJZv2AVQPJQ/m/LNU8fCuUOUEJ -- it appears that Go uses a single rounding mode.

---

For reference: https://stackoverflow.com/questions/2186788/is-there-an-open-source-c-c-implementation-of-ieee-754-operations, softfloat looks pretty good.

For now, since there are no other clear options for Go, we will use math/big.Float:

By setting the desired precision to 24 or 53 and using matching rounding mode (typically ToNearestEven), Float operations produce the same results as the corresponding float32 or float64 IEEE-754 arithmetic for operands that correspond to normal (i.e., not denormal) float32 or float64 numbers. Exponent underflow and overflow lead to a 0 or an Infinity for different values than IEEE-754 because Float exponents have a much larger range. (https://pkg.go.dev/math/big#Float.Float64)

[moul]

So happy about native time, and Bigdec!

[jaekwon]

Only UntypedBigDec is used right now (which are only made by constant expressions or constant literals) which then gets converted to float32 or float64 upon usage, but it should be easy to also support bigdec in the future if we want.
There are costs associated with bigint, bigdec operations btw, so it might make more sense to support decimal64 etc first.

[jaekwon]

this was weird. looks like before there was a bug where the native functions were only being run in files2 (when it should be so for files1 instead), and somehow the tests were still passing anyways? well, either way, the intent was this.