no_std support

[mammothbane]

Makes the crate unconditionally #![no_std] and pulls in extern crate alloc and extern crate std as configured by feature flags (std remains the default).

All functionality other than HeaderMap::try_from::<std::collections::HashMap> can be implemented with alloc + hashbrown, so this crate should be usable on embedded platforms functionally as-is.

Without alloc, we can only provide support for methods, status codes, versions, and standard header names, a pretty limited subset of functionality, though still useful for consistent types in contexts without allocation. I'd be very interested in working on a future PR adding heapless support (if the maintainers are amenable) so that most of this crate can work without an allocator, but that won't make it into this PR.

Worth noting that #732 exists -- not aiming to tread on toes, I just wasn't aware of it until I went to submit this.

All tests pass with all combinations of feature flags.

Compatibility / substantive changes

Almost all the changes in this PR are mechanical renamings of std imports to core or alloc. The next most common changes are adding #[cfg(feature = "alloc")] where appropriate.

There are no functional or compatibility changes with the std feature flag, and dropping to alloc from std only removes the HeaderMap::try_from<std::collections::HashMap> impl (while one is still provided for hashbrown::HashMap and alloc::collections::BTreeMap).

Some code changes were necessary to support non-alloc environments -- these are in header/name.rs, method.rs, and uri/scheme.rs:

• Custom header names are not parseable
• Non-inlineable extension methods are invalid
• Non-HTTP(s) schemes can't be parsed or constructed