Support for inline tests

[matklad]

When working on fall, one feature that turned out to be really useful were inline test. Basically, the idea is that you place an example Rust code alongside the grammar rules, like this:

pub rule where_clause {
  'where' <commit>
    {type_reference type_bounds {',' | <eof> | <not <not '{'>>}}*
}

test r"
fn f()
  where T: Clone + Copy, Foo: Bar
{}
"

this allows one to easily map the structure of the rules to the code which is supposed to be parse by them.

I think we should add the same feature to libsytanx. What's more, we will be using libsyntax itself to implement this feature, and that's why this issue has the fun label! So, here's the plan.

The tests will be placed in comments in the source code:

// test:
// fn foo() where T: Clone {}
// test:
// fn foo() where T: Clone, {}
fn where_clause(p: &mut Parser) {
 ...
}

Each test:

• begins with test: prefix and runs until the end of the comment or until the next test:
• is associated with a function: it either immediately precedes the function, or is inside it.
• has a name which is formed by concatenating the name of the function with a source order of the test, like where_clause_01, where_clause_02.

To actually run these tests, we reuse the usual tests/data/parser/ok machinery. Specifically, we write a tool, which parses libsyntax source code, extracts all the tests and writes each one of them as a separate file to tests/data/parser/ok directory. The tool must deal smartly with adding, removing and changing the tests. Specifically, for added tests it should add a file to the ok directory with the next test number, for removed test it should probably give an error (simply removing the test file will break tests numbering), and for changed test it should edit the existing file.

Now, the fun fact is that to write such tool, you'll need the ability to parse Rust source code, and that is exactly what libsyntax is for! Currently, it can parse only a small subset of the Rust source code, but it should be enough for the task at hand if we fill a small number of missing things and make a robust error recovery.

[matklad]

Hm, actually, I don't think we need to really parse the source code, we need only to extract line comments, and that's easier to implement by hand. Will implement this simple solution for now, but it would be cool to one-day group the tests by function name!