Add initial support for a new formatting syntax

[alexcrichton]

This pull request is the initial framework necessary for the advent of a new
string formatting system which will eventually replace fmt!. There's certainly
a lot of stuff going on here, so here's a bit of a summary:

This entire implementation is based off of the discussions had on the mailing
lists at:

• https://mail.mozilla.org/pipermail/rust-dev/2013-July/004961.html
• https://mail.mozilla.org/pipermail/rust-dev/2013-July/004999.html

It should be noted that this is not ready to actually replace the fmt! macro.
This request simply lays all of the groundwork to implement this new system.
The largest missing component is that all formatting specifiers are ignored.
Additionally, I'd like to take some time to bikeshed the format modifier syntax
after researching it a bit more.

Some notable points of the implementation

• The parser is non-trivial
  • it attempted to use conditions, but then Static variables have different addresses in different crates #8179 struck
• The sprintf function is still flagged as unsafe
• The syntax extension was written from scratch and has all of the compile-time checks the parser can't have
• A new pass was added to collect format traits into a local map
• The list of format traits are emitted to libraries so they can be loaded later on
• A new expression was added. The reasoning behind this is that macro expansion happens before crate resolution, and the list of formatting traits aren't known until after external crate resolution.

Testing wise, I've included

• parser unit tests
• runtime unit tests
• run-pass tests for all the new functionality
• lots of compile-fail tests

Note that all of the code links will become stale as I rebase, but I don't
think that anything major will be changing at this point. The best examples can
be found in the run-pass test, although there's probably a number of cases that
I've missed!

I also realize that this is very large, although I couldn't figure out a really
good way of splitting it up. If there are suggestions of how to make this a bit
more manageable, than I'd definitely take the time to split things up.

[pcwalton]

Having a separate pass for fmt trait gathering seems a little ad-hoc. The Lispy way to do this would be to have the syntax extension itself do this.

[pcwalton]

Same with the special section in the metadata. I wonder if we could have a generic way for syntax extensions to register serializable and deserializable data.

[alexcrichton]

Yeah I agree that this would be a lot better with a true syntax extension. Right now our current system of syntax extensions doesn't quite support this because it needs access to all of the crates, sadly. This is probably more of an indication that the syntax extension system should be more flexible than anything else.

[graydon]

Yeah, I"m having a hard time with the quantity of machinery here too. Especially the new metadata and expression parts. Is this all because you're trying to support user-extensible formating operator names (eg. fmt!("{z}", thing) where "z" is previously not-known to fmt!)? If so I think it might be overgeneralizing -- the set of format traits is probably small enough (and sufficiently prone to collision -- global flat namespace favoring short names!) that I think we can manually curate the list in libstd, or the fmt extension itself. I figured we'd keep that lit small-ish and assume that most of the time when users want to customize formatting, they want to do so by implementing an existing formatting-trait, not defining a whole new one.

[brson]

+1 to keeping fmt! a pure syntax extension.

[pcwalton]

+1 to Graydon's comment about manually curating the list for now.

[alexcrichton]

Sure thing, we'll lose the idea that you can create your own formatting traits, but all in all I think you guys are right that it added a bit too much stuff to the compiler. I'll reopen when I've removed all of that infrastructure.