No_std with alloc. Compiles, tests pass

[hatmajster]

Changes many std usages to core, vectors from alloc through feature with hashbrown crate for HashMap/Set.
Honestly I don't know how much of it actually compiles with pure no_std, probably very little, but I just wished for no_std with alloc, hence this PR.
I have not used this in a real app/lib yet, but I hope the changes are trivial on its own. Sadly it introduces a bit of a mess in code.
I am open to any opinions, refactors, etc. Its definitely not perfectly done. Its okay if you don't want to merge this, I'll keep the fork, but it would be really cool if it did.

[hatmajster]

Please note that any possible checks are still done for normal std. If you like I can create new workflow for no_std only - if its not a nuisance for you.

[Stoeoef]

Thanks for the PR! Adding no-std support is always a chore. But it should be feasible for spade and sounds like a good addition!
I'll look trough it in more detail within the week.

[hatmajster]

I am doing this for few crates and honestly I just learned about this: https://crates.io/crates/no-std-compat -.- It simplifies a lot. If you want I can raise another PR just to compare and pick a better one.
It basically is a dummy std crate with core/alloc methods published as if they were in std. The only change needed is that every rs file needs to have prelude included (use std::prelude::v1::*;). After that, you simply use std like you would without no_std, though only a part is available of course.
I would say that the changes I made here are better if you would like to keep attention tono_std. If you would like to just have no_std as an option and still use normal std, this compatibility crate might be a better idea (though naturally you can always see no_std compatibility via some tests). But its just how I see it, I might be wrong

[Stoeoef]

I am doing this for few crates and honestly I just learned about this: https://crates.io/crates/no-std-compat -.- ...

That's an interesting crate - thanks for sharing! It's the first time I'm hearing from that. I think there's value in unifying how no-std crates are being built though I'm being hesitant to be an "early adopter" - the crate doesn't seem to be super wide spread as of now.
For spade I'd prefer to make it a no-std crate manually without adding an additional dependency - let's keep the approach in this PR for now!

[Stoeoef]

Review done!

I've found a lot of liking to the idea to be no-std by default. This will require a few changes (nothing major though?) and should be an overall simplification.

Once that's done this PR should be ready to go.

[Stoeoef]

Please note that any possible checks are still done for normal std. If you like I can create new workflow for no_std only - if its not a nuisance for you.

Yep, I plan to add that and some additional documentation.

[Stoeoef]

Feature is available with v2.3.0 on crates.io