more no_std support

[zendurix]

I have implemented most functions to be able to use in no_std with alloc (by using optional feature use_alloc). Also I have included optional crate hashbrown (it is used while using use_alloc) for no_std Hashmap.
Everything builds and tests are passing in both default and no default with feature use_alloc.
There are many changes due to cargo fmt, if this is a problem I can return them to previous formatting, however this will require some manual work.

[jswrenn]

however this will require some manual work.

Massive patches create additional labor for reviewers. It's good etiquette to minimize patch size. Could you please submit which changes only the necessary lines?

[zendurix]

however this will require some manual work.

Massive patches create additional labor for reviewers. It's good etiquette to minimize patch size. Could you please submit which changes only the necessary lines?

Do you mean to redo thoose cargo fmt changes, or just mark lines that I have changed ?

[jswrenn]

A PR without any cargo fmt changes. Marking the meaningful changes isn't sufficient: I trust that you did not sneak any changes in, but I cannot merge any PR without reviewing every modification.

PRs that change many lines are also very likely to invalidate other pull requests, creating additional work for those authors. The bigger the PR, the lower priority of review it tends to get.

[sollyucko]

FYI, you could probably git reset HEAD^ then git add --edit each file with useful changes, to select which changes to include.

[zendurix]

I have fix the cargo fmt problem, only relevant changes are now left.
Please do cargo fmt after merge to avoid this next time :p

It passed no std check
https://github.com/mystor/cargo-no-std-check

[jswrenn]

Hashbrown doesn't seem to have a minimum-supported-Rust-version policy—Itertools does. We therefore can't just drop-in hashbrown as an alternative to std::collections::HashMap.

[jswrenn]

I've opened #474, which implements a minimal use_alloc feature.

I'm happy to revisit porting HashMap support to use_alloc in the future, but I'd like to take a carefully considered, incremental approach to doing so.