Add #![no_std] compatibility

[poshcoe]

Adds #![no_std] (with alloc) compatibility by introducing a "std" cargo feature.

I'm interested in evaluating bitcode for embedded applications. I found adding support relatively painless, most of the changes are swapping use std::* for use::core::*, and adding explicit use of alloc.

Notable changes:

• HashMap and HashSet implementations for Decode and Encode are disabled for no_std
• Added an unrelated improvement to the thread_local here, utilising the const syntax which should improve efficiency by avoiding runtime initialisation checks.
• As thread_local! is std-only, I added a separate impl_u8! which falls-back to allocating the "scratch space" on each pack8/unpack8 call. See below images for benchmarks on the impact of this change (target_arch = "x86_64").

cargo +nightly bench bench_pack:

cargo +nightly bench bench_unpack_u:

At a glance the performance impact is minimal, resulting in a < 1% average performance deficit on both pack and unpack without std.

It remains to be seen if bitcode performs well on no_std target architectures. I'll likely be testing this in the near future.

[finnbear]

Thanks for the PR! LGTM. In the interest of not inadvertently breaking #![no_std] in the future, is it possible to add a GitHub Actions job that runs a subset of the tests?

[poshcoe]

In the interest of not inadvertently breaking #![no_std] in the future, is it possible to add a GitHub Actions job that runs a subset of the tests?

Sure, I'll tack it on along with fixes for the lints

[poshcoe]

I also took the chance to enable compat of the "serde", "glam" and "arrayvec" features with #![no_std].

The new test therefore enables --features derive,serde,glam,arrayvec

[caibear]

Build is failing because cargo fmt's output changed between nightly-2023-04-25 and your rust version.

[caibear]

Ok, I've fixed the issues I noticed.

[poshcoe]

thanks!