macro_rules! is like an item that defines a macro.  Other items don't have a
trailing semicolon, or use a paren-delimited body.

If there's an argument for matching the invocation syntax, e.g. parentheses for
an expr macro, then I think that applies more strongly to the *inner*
delimiters on the LHS, wrapping the individual argument patterns.

Instead of copy-pasting the whole macro_rules! item from the original .rs file,
we serialize a separate name, attributes list, and body, the latter as
pretty-printed TTs.  The compilation of macro_rules! macros is decoupled
somewhat from the expansion of macros in item position.

This filters out comments, and facilitates selective imports.

In the future we want to support

    #[macro_use(foo, bar)]
    mod macros;

but it's not an essential part of macro reform.  Reserve the syntax for now.

In preparation for the rename.

Many of libstd's macros are now re-exported from libcore and libcollections.
Their libstd definitions have moved to a macros_stage0 module and can disappear
after the next snapshot.

Where the two crates had already diverged, I took the libstd versions as
they're generally newer and better-tested. See e.g. d3c831ba, which was a fix to
libstd's assert_eq!() that didn't make it into libcore's.

Fixes #16806.

Fixes #17103.

The implementation of LetSyntaxTT was specialized to macro_rules! in various
ways. This gets rid of the false generality and simplifies the code.

This commit moves the libserialize crate (and will force the hand of the
rustc-serialize crate) to not require the `old_orphan_check` feature gate as
well as using associated types wherever possible. Concretely, the following
changes were made:

* The error type of `Encoder` and `Decoder` is now an associated type, meaning
  that these traits have no type parameters.

* The `Encoder` and `Decoder` type parameters on the `Encodable` and `Decodable`
  traits have moved to the corresponding method of the trait. This movement
  alleviates the dependency on `old_orphan_check` but implies that
  implementations can no longer be specialized for the type of encoder/decoder
  being implemented.

Due to the trait definitions changing, this is a:

[breaking-change]

This "reexports" all the functionality of `core::char::CharExt` as
methods on `unicode::u_char::UnicodeChar` (renamed to `CharExt`).

Imports may need to be updated (one now just imports
`unicode::CharExt`, or `std::char::CharExt` rather than two traits from
either), so this is a

[breaking-change]

Imports may need to be updated so this is a

[breaking-change]

This commit introduces the syntax for negative implmenetations of traits
as shown below:

`impl !Trait for Type {}`

cc #13231
Part of RFC #3