Investigate gradual migration path of crux_http to `http`

[charypar]

The HTTP capability currently uses http-types, which does not look actively maintained, and probably isn't the first choice for common HTTP types today. We also rely on a custom fork to avoid compatibility issues with emscripten (see https://github.com/redbadger/crux/pull/195).

From a quick look, it may be possible to switch to http, but maintain backwards compatibilty with http-types temporarily under a feature flag. That way we wouldn't force people to migrate or stay behind. It's not easy to see whether this is possible and how hard it might be without trying, which is what this issue is about.

It is quite likely to make the code very annoying to read for the duration of maintaining both versions.

Sketch implementation:

• introduce a http-types feature flag to crux_http
• guard all uses of the types from the crate with a feature flag and...
• switch to either an equivalent from http or to our own type if an equivalent doesn't exist (I think this is the case for the Body type, which is just a generic argument in http)

If this becomes far too messy, we will have to just bite the bullet and make people migrate the types as a step change, providing helpful conversion traits where we can, etc.

[charypar]

A few hours investigation suggests this should be reasonably possible, but will require a few days work.

I'll open a PR some time in the following days or weeks.

[charypar]

Just for anyone watching this - this turned out really quite painful, and coupled with the other changes to HTTP, the more likely outcome is a hard switch from http-types to http - the impact might be quite high for people who use lots of details of HTTP, but I'm hopeful most have a central HTTP client for this case, so it's at least localised, and not scattered around in a hundred places.

In case you depend on the re-exported http-types heavily, please get in touch.