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.

### 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)

### 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..