Service enhancement prerequisites for XFR support

[ximon18]

Taken from the xfr branch in order to split PR #335 into several smaller PRs.

This PR makes changes, some of which are breaking (i.e. not backward compatible with earlier unstable server functionality without minor adjustments to existing consumer code, e.g. see the changes to examples/serve-zone.rs), including:

• Adds support for indicating to downstream Service impls that a certain number of bytes should be reserved (to make space for adding a TSIG RR or EDNS options during middleware post-processing).

• Adds support for strongly typed passing of arbitrary metadata between middleware that produces a type and middleware that consumes the type (e.g. passing the used TSIG key name from TSIG middleware to XFR middleware).

• Replaces the blanket impl Service for Arc with a more general impl Service for Deref.

• Removes the blanket impl Service for fn as I have multiple times been blocked from defining some other Service impl because the fn one matches, because its presence can cause very confusing compiler error messages if your impl Service for T is not quite in sync with the signature of your other impl T blocks, and because Hyper doesn't need it so why do we?

• Adds an "enabled" flag to the CookiesMiddlewareSvc (and later the TsigMiddlewareSvc will have it as well) making it easier to create a service stack with optionally enabled layers based on runtime configuration.

There was some internal discussion today with @Philip-NLnetLabs about passing data between middleware layers instead as a map of string key to some value pairs, or adding an enum to Request with things that a middleware might need (e.g. TSIG key name, or other arbitrary T), but that isn't reflected (yet?) in this PR.

The upside of the approach in this PR is it allows a producing middleware to express the metadata type it produces and a consuming middleware to express compatibility with a certain metadata type (e.g. via a trait impl, see 88a8f02) and to then have compile time checking that the middleware are compatible with each other, without having to express up front every possible data that might need to be passed around with a request or else as some arbitrary Other(T). But I'm undecided about the best way to do this ...

The changes in this PR currently lack RustDocs, and testing (as the consuming and testing is done at the point of use in the xfr branch).

[Philip-NLnetLabs]

Looks good to me except for start_error.