Add support for `no_std` compilation (updated)

[pitdicker]

See discussion in #74.

This is useful to fuzz crates in their no_std configuration, which may utilize different code paths in such a crate.

I started by rebasing #74 but made a number of changes to split it in an std and alloc feature.

Fixes #38.

[fitzgen]

This was the conclusion of #74: https://github.com/rust-fuzz/arbitrary/pull/74#issuecomment-902114435

[pitdicker]

What do you think of the use case mentioned above?

This is useful to fuzz crates in their no_std configuration, which may utilize different code paths in such a crate.

[pitdicker]

I am not sure how to replicate the warnings in the "Run int_in_range fuzz target" CI job. Hopefully this fixes it.

[nagisa]

@fitzgen counter question to the implementation constraints concern: is it really as bad as your comment makes it seem to restrict ourselves to libcore in the few circumstances where doing so would be necessary? I'm asking because arbitrary is largely a collection of impl Arbitrary for .... Since most of the implementing types hail from libstd, those will be able to use std in their implementation. Outside of the Arbitrary trait and the few impls for the basic libcore types, everything else (including Unstructured) can be made libstd-only and considered for no_std compatibility on a case-by-case basis. Wouldn't that be good enough?

[refcell]

Landing this would be highly appreciated.