syntax: Refactor diagnostics to focus on Writers

This commit alters the diagnostic emission machinery to be focused around a
Writer for emitting errors. This allows it to not hard-code emission of errors
to stderr (useful for other applications).
librustc: Pass the node id so we don't fail on destructing struct variants. Fixes #11577.
rustdoc: Capture all output from rustc by default

This helps prevent interleaving of error messages when running rustdoc tests.
This has an interesting bit of shuffling with I/O handles, but other than that
this is just using the APIs laid out in the previous commit.

Closes #12623
librustc: Don't ICE when operator traits are not implemented properly. Fixes #11450
std: Change assert_eq!() to use {} instead of {:?}

Formatting via reflection has been a little questionable for some time now, and
it's a little unfortunate that one of the standard macros will silently use
reflection when you weren't expecting it. This adds small bits of code bloat to
libraries, as well as not always being necessary. In light of this information,
this commit switches assert_eq!() to using {} in the error message instead of
{:?}.

In updating existing code, there were a few error cases that I encountered:

* It's impossible to define Show for [T, ..N]. I think DST will alleviate this
  because we can define Show for [T].
* A few types here and there just needed a #[deriving(Show)]
* Type parameters needed a Show bound, I often moved this to `assert!(a == b)`
* `Path` doesn't implement `Show`, so assert_eq!() cannot be used on two paths.
  I don't think this is much of a regression though because {:?} on paths looks
  awful (it's a byte array).

Concretely speaking, this shaved 10K off a 656K binary. Not a lot, but sometime
significant for smaller binaries.
auto merge of #12626 : alexcrichton/rust/assert-eq, r=thestinger

Formatting via reflection has been a little questionable for some time now, and
it's a little unfortunate that one of the standard macros will silently use
reflection when you weren't expecting it. This adds small bits of code bloat to
libraries, as well as not always being necessary. In light of this information,
this commit switches assert_eq!() to using {} in the error message instead of
{:?}.

In updating existing code, there were a few error cases that I encountered:

* It's impossible to define Show for [T, ..N]. I think DST will alleviate this
  because we can define Show for [T].
* A few types here and there just needed a #[deriving(Show)]
* Type parameters needed a Show bound, I often moved this to `assert!(a == b)`
* `Path` doesn't implement `Show`, so assert_eq!() cannot be used on two paths.
  I don't think this is much of a regression though because {:?} on paths looks
  awful (it's a byte array).

Concretely speaking, this shaved 10K off a 656K binary. Not a lot, but sometime
significant for smaller binaries.
auto merge of #12627 : alexcrichton/rust/issue-12623, r=brson

This helps prevent the unfortunate interleavings found in #12623.
auto merge of #12638 : luqmana/rust/op-no-ref, r=alexcrichton

From my comment on #11450:

The reason for the ICE is because for operators `rustc` does a little bit of magic. Notice that while you implement the `Mul` trait for some type `&T` (i.e a reference to some T), you can simply do `Vec2 {..} * 2.0f32`. That is, `2.0f32` is `f32` and not `&f32`. This works because `rustc` will automatically take a reference. So what's happening is that with `foo * T`, the compiler is expecting the `mul` method to take some `&U` and then it can compare to make sure `T == U` (or more specifically that `T` coerces to `U`). But in this case, the argument of the `mul` method is not a reference and hence the "no ref" error.

I don't think we should ICE in this case since we do catch the mismatched trait/impl method and hence provide a better error message that way.

Fixes #11450
auto merge of #12639 : luqmana/rust/struct-variant-pat, r=pcwalton

We weren't passing the node id for the enum and hence it couldn't retrieve the field types for the struct variant we were trying to destructure.

Fixes #11577.
std: Flush when buffered writers are dropped

It's still not entirely clear what should happen if there was an error when
flushing, but I'm deferring that decision to #12628. I believe that it's crucial
for the usefulness of buffered writers to be able to flush on drop. It's just
too easy to forget to flush them in small one-off use cases.

cc #12628
std: Switch stdout/stderr to buffered by default

Similarly to #12422 which made stdin buffered by default, this commit makes the
output streams also buffered by default. Now that buffered writers will flush
their contents when they are dropped, I don't believe that there's no reason why
the output shouldn't be buffered by default, which is what you want in 90% of
cases.

As with stdin, there are new stdout_raw() and stderr_raw() functions to get
unbuffered streams to stdout/stderr.