Testing all features instead of just a specific set makes it possible
for the CI to spot various mistakes in currently-untested doc comments,
such as those behind the `http-interop` feature.  More importantly,
enabling _all features_ on docs.rs as well massively helps visibility
in available features and functionality to the end user.  And `doc_cfg`/
`doc_auto_cfg` automatically provide them the right information block
with a (list of) feature(s) they need to enable to get access to a
certain type or function.

Note that this requires a `nightly` feature and is hence behind a
`--cfg` flag that is only enabled when building for docs.rs (using
`nightly`). It can be reproduced locally via `RUSTDOCFLAGS=--cfg=docsrs
cargo +nightly doc`.

Additionally the CI script is updated to pass `-Dwarnings` to `rustdoc`
so that it can adequately fail the CI when incorrect documentation is
encountered.

…tems

I added `--all-features` in #670 without removing `--no-default-features`
which now has no effect anymore.

In addition it is useful to make sure that documentation on private items
also adheres to valid intradoc, and somewhat strangely enabling this also
causes additional lint warnings on public documentation...

As mentioned in #670 (comment)
this sort of documentation is superfluous now that `doc_cfg`/
`doc_auto_cfg` **automatically** generates colored blocks in the
documentation denoting what `cfg`s (including features) need to be met
in order to enable a symbol.

In addition the `http` feature only exists to turn on the `http` crate,
while the type conversions in the `http_interop.rs` module are only
provided behind the `http-interop` feature.

The `charset` feature documentation is left in place, because that
affects additional functionality deeper down inside the `send_string()`
function.

I found the current conversion for `http::request::Builder` to be
rather useless when the `http` crate and various crates providing `http`
interfaces like `oauth2` are designed to provide an `http::Request`
directly, and there being no way to convert from a `http::Request`
back into its `http::request::Builder`.  That, together with strange
infallible defaults instead of providing  `TryFrom` make the current
implementation cumbersome to use.

Fortunately `http` provides `http::Request::into_parts()` to get
back a `Parts` structure (which is wrapped in `Result<>` inside
`http::request::Builder` as sole member!) together with the request body
(a generic type) which the user can manually pass to `send_string()`,
`send_bytes()` or `call()` if there's no data.

Implement a `From<http::request::Parts> for ureq::Request` to support
this case, making `ureq` finally capable of sending `http::Request`s.
(Note that, despite exclusively consisting of `Result<Parts>`,
 `http::request::Builder` has no constructor from `Ok(Parts {..})` which
 would have also facilitated this use-case somewhat)

…ngly) skipped during conversion

The current interop implementation forces fallibility around header
values when they are not UTF-8, both in conversions from `http` to
`ureq` as well as the other way around.

This should not be necessary as both `http` and `ureq` treat these as
opaque byte arrays internally, but unfortunately the current open API
for `ureq` and `http` make it a bit nasty to deal with.

Upon upgrading to 2.8.0, I got the following compile error from inside `ureq`:

    error[E0599]: no method named `add_trust_anchors` found for struct `RootCertStore` in the current scope
       --> /home/cdown/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ureq-2.8.0/src/rtls.rs:102:16
        |
    102 |     root_store.add_trust_anchors(webpki_roots::TLS_SERVER_ROOTS.iter().map(|ta| {
        |     -----------^^^^^^^^^^^^^^^^^ help: there is a method with a similar name: `add_server_trust_anchors`

The reason is because `add_trust_anchors` was only added in rustls
0.21.6, but ureq only specifies that any 0.21 is required. As such, if
you are already using a compliant, earlier version, the method does not
exist and the compile fails.

Pin to >=0.21.6 to make sure this method exists.

Originally introduced in 50fd1fe ("Update deps").

…o detect proxy settings from environment by default

…e `proxy-from-env` feature flag

In the context of ureq "http" is a bit too generic feature name to use
for the http crate interop. Instead we use "http-crate" for the 1.0
dependency.