Transform and format + more more more!

I did a bit of a design rework of `rustfmt`, pursuing my instincts as I learned more about the code in order to separate out two separate tasks I felt were getting too intertwined in the code: Transformation of the token stream and the actual formatting of said stream.

A lot of this work of doing refactors that I felt were needed to get the codebase into shape for future improvements, but the deliverables are the bugs fixed, noted below.

It builds on the latest nightly

### License/authors stuff

I went ahead and threw an MIT License on the project. I added `LICENSE.txt`, `AUTHORS.txt` and license notices to every `.rs` file. I put Patrick Walton as the author in all files and added the others in `AUTHORS.txt`. Not sure if there's a better way to skin this cat. I'm lazy.

### Bugs fixed!

1. We have comments! this is a tad rough and could be beefed up a bit.. I can work on this some more if desired. Closes #1
2. Support preserving (a single) blank line in code (more on this below) Closes #3

### Transform/Format

In line with this, I broke the process into two steps involving a complete run through the input tokens:

1. A `transform` step, that takes in an immutable slice of `TransformedToken` (more on that later) and returning a `Vec<TransformedToken>`. It is free to take one-or-more tokens from the lexer and replace them with something else that can interpretted in the...
2. `format` step that is largely representative of the original impl of `rustfmt`. It has grown logic to deal with different constructs contained within `TransformedToken`

More about `TransformedToken`. It has three variants:

1. `LexerVal(TokenAndSpan)` - this takes the place of what was previously just the `TokenAndSpan` for everything.. serves the same purpose
2. `BlankLine` - represents a `token::WS` whose snippet indicates that it contains (at least) two newlines, hence collapsing it down to a single newline.. this is part of the logic I added to collapse multiple blank lines in parsed code down to a single blank line
3. `Comment(String, bool, bool)` - information on the comment's snippet (so that `format` doesn't depend on the `SpanHandler`, and information on whether the comment is preceeded or followed by a newline (useful for inline comments, multilines, line-ending comments following a `token::SEMI`, etc etc etc)

This is the solution I came with for dealing with comments/empty-lines. Not marvelous but it gets the job done. I'm not super experienced with actual compiler-level work in rust (did most of my contributions in runtime/stdlib), and I think it shows. But I got passing tests!

### The Future

I see the transform/format stuff as being able to be extracted out to configuration params ala lint configuration.

I kind of feel the need for some kind of component level parsing (like args to methods, chains of method calls, etc) so that we could take a look at enforcement column-width (which seems pretty far out.. I haven't put a ton of thought into it, yet). I'm not sure if parsing to the AST is appropriate, here. Please let me know.

I want to laser-focus the tests a bit more. There are a few large'ish tests that cover a bunch of language constructs that all fail whenever changing the code, because they all straddle several constructs. I would like to tighten that up so that breaking one language feature can lead to just breaking a single test..

All of this plays together with my desire to start driving towards implementing and enforcing the rust style guide, as it currently exists. Not sure how to approach this.
Mozilla Foundation