Previously we'd get an error if the first lines in the mappings file
were blank or comments.

This broke recently I think. You can no longer have a mappings file that
starts with blank lines or comment lines.

Removing the empty and blank handler in `definitions()` fixes the tests
added by this commit but fails these:

    parser::tests::map_group_empty_input_does_not_fail
    parser::tests::map_group_skipped_input_outputs_default_map_group

Using this diff:

    diff --git a/src/parser.rs b/src/parser.rs
    index 3f3d7b9..d18b56a 100644
    --- a/src/parser.rs
    +++ b/src/parser.rs
    @@ -629,11 +629,11 @@ where
         I: Stream<Item = char>,
         I::Error: ParseError<I::Item, I::Range, I::Position>,
     {
    -    or(
    -        (
    -            blank(),
    -            eof(),
    -        ).map(|_| MapGroup::default()),
    +    // or(
    +    //     (
    +    //         blank(),
    +    //         eof(),
    +    //     ).map(|_| MapGroup::default()),
             (
                 definitions(),
                 eof(),
    @@ -661,8 +661,8 @@ where
                 }

                 map_group
    -        }),
    -    )
    +        })
    +    // )
     }

     fn comment<I>() -> impl Parser<Input = I>

Need to figure out some way to get both sets of tests to pass.

Remove the TODO key and use a real one instead. A description of the
program.

Check that the desired error messages appear for a couple extra invalid
mapping definitions.

Rename the existing `map_group_shows_error_in_middle_of_line()` test to
use the naming pattern of the two new tests.

The new tests check that the right errors appear in map actions, and for
missing the closing brace on a mode definition.

Just noticed this. Seems it served its purpose.

In addition to asserting the position of the error, also check that it's
the error we expect by looking for an unexpected 'n' token.

This seems to fix the problem of errors in the middle of definitions not
being surfaced (what the test in
3091ebe0deb1ba832b4a5925263409ec5b651c62 is for).

Need to write some more tests for other error cases.

The reason why this happens is because `try()` causes the parser to not
consume the input. Since the input isn't consumed, I guess the error
messages from within never get surfaced. Moving the `try()` further down
the parser tree appears to fix things.

I wrote the wrong column number on which the error should occur.

Since the errors are going to be different from what's written in the
test expectation, just remove them to correct the test. We kind of only
care about the position. Maybe the first error would be interesting to
match on, but let's just get rid of the part we know is wrong.