[WIP] no_std support

[VictorKoenders]

Started working on no_std support

⚠️ This is a breaking change ⚠️

This PR adds 3 new features:

• std (enabled by default)
• alloc has no std support, but does support strings, collections and boxes
• no features, no_std. This disables all allocations and OS-specific code.

The changes in this PR are: (unchecked features are not final)

• std::io::Read/Write doesn't exist in core (tracking issue) This is solved by implementing our own Read/Write traits
• std::io::Error and std::error::Error are also not available. We create our own io error type, and we explicitly implement serde::de::Error when we're in no_std mode
• byteorder::ReadBytesExt and byteorder::WriteBytesExt are not available outside of std mode. (Related issue that states that they're waiting on RFC 2262)

[Plecra]

I think there's a much better solution for us to find before taking this route. Maintaining three versions of the primitives the library uses is asking for subtle, annoying bugs to track down. And we'd also be forcing that inconvenience on users - they'd have to deal with an Error type that didn't actually implement 90% of the documented API.

We floated the idea of a separate crate for the no_std implementation, which would also give us a chance to clean up the API. It doesn't need to have anything to do with std::io if we use an associated error type in a trait akin to serde_json::de::Read.

[ghost]

Yeah, I would be interested in making a bincode_core crate, beraking whatever you want in that. And reshimming it to match the bincode api from the bincode crate.

[VictorKoenders]

Zoey and I started work on bincode-core here: https://github.com/bincode-org/bincode-core

Closing this PR in favor of that