First version of the formatter

Summary: We need a code formatter for serveral reasons:
1) Nice to have for the IDE (and vim/emacs)
2) Must have to write non-trivial refactoring tools
3) Would be nice to have before commit (not ready for that)

A while back, I tried to write a pretty-printer based on an AST.
I then tried to extend the tree with textual elements
(comments, newlines etc ...) and make the algorithm take them into account.

It was an epic failure. The textual elements did not "fit" well in the tree,
they were arbitrarily added in places that didn't always make sense.

Because of that, the code was difficult to follow. What it boils down
to is that the textual elements should be part of the logic while formatting.
An Ast is a poor representation because it either ignores textual elements or
includes them in a very "ad-hoc" fashion (attaches them to tokens).

So I tried a radically different approach: the formatter is structured like a
recusive descent parser. Because the token stream includes textual elements,
we have a lot more context (the state of the parser) to decide what to do with
them.

The output of the parser is not a tree, it uses a mini-DSL describing
what the output should look like (e.g. [newline; last_token; semi_colon]).

This first version is not meant to be perfect. I tried it on our codebase and
glossed over the result. I did check the following though:
-) All of www is formatted without errors
-) The formatter is idempotent
-) The result of the formatter always parses

I kept the option --debug (works on a directory) to carry on running these
tests while the code evolves.

However, I did not include a list of unit tests, because I think its going to
be really tedious to maintain. I didn't try to make the formatter work on files
that containt parsing errors for similar reasons.

What I would like to do instead is to plug the formatter into the IDE to:
  -) Log when the formatter failed because of a syntax error
  -) Log when the user edited the result of a formatted region.
     This consists in two steps, first, look if the comments are the same,
     then look if the trees are the same, if they both are: the user was
     unhappy with the formatting.

Once we have that data, we will know what kind of parsing errors we should try
to recover from and how often users are unhappy with the result of the
formatter.

It will then be the right time to adapt the code so that it recovers from
parsing errors and adjust the output to look like what most users want.
If this approach works, we might be able to systematically apply the formatter
before committing.

If you are interested in plugging the formatter into a tool:
cat the_buffer | hh_format --from absolute_char_pos_begins --to where_it_ends

Reviewed By: @jwatzman

Differential Revision: D1406466