Support for #![no_std]

[Aeledfyr]

This PR adds partial support for using piccolo from #![no_std] platforms.

This relies on a tiny patch to gc-arena to make the allocator-api2 feature work under #![no_std]; my patch for this is here: kyren/gc-arena@4d52634

However, piccolo currently uses an old version of gc-arena, so I'm not sure whether it would be better to update to the latest version before fixing that and merging this.

I'd recommend reading through the diffs for each commit rather than the whole PR, because the import changes touch basically every file and make the diffs unreadable.

The major changes in this PR:

• Switches the input to the lexer and parser to be a byte slice rather than impl io::Read
• Moves io-specific operations (src/io.rs, src/stdlib/io.rs) under a new std feature, enabled by default
• Moves rng-requiring operations (math.random, in src/stdlib/math.rs) under a new rng feature, enabled by default
• Moves most floating point functions in math behind the std feature, as Rust's core library doesn't provide them. We could work around this by adding an explicit dependency on a libm equivalent.
• Replaces an explicit std::process::abort() with a double panic in util/src/freeze.rs -- please check to make sure I did that right! A double panic should always abort, but I don't know if it has the same guarantees as std::process::abort().

Here are the current limitations:

• Without the rng feature, HashMap randomization will be mostly disabled, which can allow for denial of service attacks
• The rng feature should work on #![no_std], but will require the user to set up getrandom's randomness source: https://docs.rs/getrandom/latest/getrandom/#custom-backend
• Most of the floating point math operations in math are missing in no_std
• Floating point exponentiation is disabled in no_std

[orsinium]

Fantastic! I did pretty much the same work before I found this PR. The main difference is that I want to bring it incrementally, with #136 being the first PR.

I'm stuck at upgrading gc-arena, see kyren/gc-arena#133. If I see that @kyren is not currently accepting PRs, I plan to fork both projects and rollback the breaking changes from gc-arena. And hopefully then it all will be working.

[notxvilka]

@orsinium I recommend checking other PRs in the repository too - there are many good improvements but hang here forever without even being reviewed.

P.S. If you plan a maintained fork, please let us know, it sounds interesting.

[orsinium]

I'm not sure about actively maintaining, since I'm not a Lua developer. But I want to have something working for no_std to run Lua apps in Firefly Zero, the wasm-powered game console that we're making. I'm not aware of any other Lua implementations that would work for wasm-unknown target: the mainstream Lua interpreter can only work with emscripten polyfill. And having Lua support is essential for porting PICO-8 games.