Add support for no_std

[antangelo]

This PR adds the "std" default feature, and allows the crate to be build with no_std by disabling it.

Most changes are straightforward, changing imports to use core and alloc equivalents over std. Beyond that,

• Uses of std::error::Error are conditionally replaced with core::error::Error. This is currently unstable, so nightly is required for no_std usage for the time being. I believe it is still not possible to build a no_std binary without nightly, so this should be an acceptable requirement.
• thiserror has been replaced with a fork thiserror-core, that supports no_std. A PR is open on the original to support it, but has yet to be merged. This library also makes use of core::error::Error, and thus requires nightly when no_std is used.
• I was unable to create a set of traits that could serve as Read/Write in no_std and be blanked impl'd as their std counterparts when the std feature is enabled. As an alternative, I did the following:
  • std::io::{Read, Write, Error, ErrorKind} are re-exported under crate::io when std is enabled.
  • When std is disabled, a separate no_std implementation of the above is exported to crate::io.
  • I have not implemented every trait method on Read or Write in the no_std case, only those necessary. The remaining ones can be implemented by downstream users off of read or write directly if needed.
• Tests are modified to run against either the std or no_std build. They are probably going to be run on a target with std support, and as such import std themselves. I've also added an extra test case that does not make use of std.
• Verbose println statements are moved into a macro, which is conditionally enabled on the std feature.
• I have added additional CI pipelines to check, test, and lint the no_std build of the crate.
• The binaries in this crate have not been changed to support no_std, they just instead depend on the std feature being enabled.

I've tested this in a baremetal i386 project of mine with success. Haven't tried the webassembly use case.

Resolves #15

[KillingSpark]

Amazing work! I'll be busy the next few days so review might take a bit, but it is much appreciated 👍

[KillingSpark]

Haven't tried the webassembly use case.

Haven't run anything with it but it compiles for the --target wasm32-wasi which seems like a good sign :)