…erate `no_std` code

The alternative is to get collections types from `core` and `alloc`.
In the `no_std` mode in `prost_build`, we force it to always use BTreeMap
since HashMap was not stabilized in `alloc::collections` library.

The functionality is identical and the only incompatibilities in the interface
are that we cannot use `std::error::Error` or `std::io::Error` in `no_std` mode
because these types have not been moved to `alloc` and there is no alternative.

This also uprevs `bytes` dependency to 0.5, and fixes up breakage after IntoBuf api
is removed in `bytes` crate.

Note that for now, we put a patch to `bytes` to pin to a specific commit in master,
since bytes `0.5` is not released yet.

…ntified

…rive

as a workaround for feature-unification issues

Merge in 0.6.1 changes into no_std fork

Leaves the "use_alloc_collections_lib" stuff because that helps
people who don't want to write BTreeMap everywhere. But maybe it
should go also, and they should have to do that.

This option is helpful if someone needs to make the code-gen be
no_std compatible, otherwise they have to enumerate all the btree types
in their build.rs which is onerous

This allows simplifying tests a bit, removing unnecessary `extern crate alloc;`

…ost-derive

This allows to remove `extern crate alloc;` from `protobuf` crate,
and I think it means that users who don't care about `no_std` don't
have to write `extern crate alloc;` to use prost