Introduce a new base module

[bal-e]

This introduces a new_base module as a potential candidate for replacing base. While it has a similar structure, it has some distinguishing features:

1. It uses concrete types (usually slices and references) in place of Octs generic parameters. The hard-coded types are ergonomic and efficient and simplify the API.

2. It introduces a new parsing architecture which aggressively avoids copying. The architecture is inspired by the zerocopy crate, but allows for partial copying when zero-copy is not possible. derive macros are provided (and heavily used internally) to avoid boilerplate when implementing the parsing traits.

3. It overhauls the message building process so that truncation errors are handled more gracefully and message components (i.e. questions and records) can be built incrementally. This lays the groundwork for a more efficient client/server architecture where messages are built in-place, even across middleware layers.

4. It introduces RevName, a more efficient type for domain names (where labels are stored in reverse order). Operations on RevName tend to be more efficient (e.g. canonical-order comparisons are significantly better).

Here's the current roadmap:

• Define basic DNS types (messages, questions, records, etc.).
• Define low-level parsing and building traits.
• Define derive macros for the parsing/building traits.
• Define some record data types (probably those from RFC1035).
• Define the OPT record data, and some EDNS option types.
• Finalize the design of the wire-format parsing traits.
  • Add derive macros for these traits.
• Design high-level parsing/building traits for entire DNS messages.
  • Define types for common cases (e.g. simple query messages).
  • Add derive macros for these traits.
• Overhaul net::server (in a separate PR) on top of new-base.

Note: this is a new version of #469 with a less problematic branch name.