Base Library Adjustments for Latest Motoko RTS

[luc-blaeser]

Adjusting the base library for latest Motoko RTS changes:

• Also test enhanced orthogonal persistence with Wasm Memory 64.
• Be prepared for the RTS dependency upgrade chore: Upgrade RTS Dependencies motoko#4677

Changes:
The original Musl float formatter has been replaced by the Rust implementation with some subtle format changes:

• Numbers are displayed with the actually defined precision, no longer truncating trailing zeros and potentially revealing existing numeric errors.
• The exponent is printed with an explicit sign and multiple digits.
• NaN is formatted differently, now NaN, while the NaN sign bit is omitted.
• The hexadecimal float formatter is no longer supported (Float.format(#hex)). This is probably acceptable as it is rarely used.

Once we have dfinity/motoko#4677 merged in Motoko master, then we can remove the backwards compatibility of float formatting in these tests. Backwards compatibility is here needed to make motoko-base tests pass with the old Motoko compiler version.

[crusso]

FTR there's a crate that supports hex formatting https://crates.io/crates/hexfloat2, but perhaps we can't use it (or don't want to).

[crusso]

I wonder if this PR should actually go into branch next-moc, not master, since that is what we test against in the motoko repo.

After the merge, we'd have to adjust moc's nix/sources.json to reference the commit on next-moc.

When we make a release of base, the changes from next-moc will be merged into master.

Moc's ci actually tests against motoko-base/next-moc. I was confused why this works currently but I guess it's because, prior to this PR, the moc CI would only test the classical version of the compiler, whose behaviour is still unchanged until we dump musl, right?

[luc-blaeser]

FTR there's a crate that supports hex formatting https://crates.io/crates/hexfloat2, but perhaps we can't use it (or don't want to).

This looks interesting and also quite small. Certainly worth to try. Will put this on my backlog. Thank you for pointing to this library!

[luc-blaeser]

I wonder if this PR should actually go into branch next-moc, not master, since that is what we test against in the motoko repo.

After the merge, we'd have to adjust moc's nix/sources.json to reference the commit on next-moc.

When we make a release of base, the changes from next-moc will be merged into master.

Moc's ci actually tests against motoko-base/next-moc. I was confused why this works currently but I guess it's because, prior to this PR, the moc CI would only test the classical version of the compiler, whose behaviour is still unchanged until we dump musl, right?

Thanks for explaining. You are right. I rebased the PR on next-moc.
Btw: The CI indeed only runs against the old musl. This PR would permit both float output formats in the tests, with and without musl. As soon as we have fully removed musl from both classical persistence and EOP, we can switch back to one expected format.