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 #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.