line_debug.t: Add diagnostics
Fix debugger lines with keyword <newline> =>

Commit 2179133 (in 5.19.2) modified the parser to look past newlines
when searching for => after a keyword.  In doing so, it stopped the
parser from saving lines correctly for the debugger:

$ PERL5DB='sub DB::DB{}' perl5.18.1 -detime -e'=>;' -e 'print @{"_<-e"}'
sub DB::DB{};
time
=>;
print @{"_<-e"}
$ PERL5DB='sub DB::DB{}' perl5.19.3 -detime -e'=>;' -e 'print @{"_<-e"}'
sub DB::DB{};
=>;
print @{"_<-e"}

Notice how line 1 is missing in 5.19.3.

When peeking ahead past the end of the line, lex_read_space does need
to avoid incrementing the line number from the caller’s (yylex’s) per-
spective, but it still needs to increment it for lex_next_chunk to put
the lines for the debugger in the right slot.  So this commit changes
lex_read_space to increment the line number but set it back again
after calling lex_next_chunk.

Another problem was that the buffer pointer was being restored for a
keyword followed by a line break, but only if there was *no* fat arrow
on the following line.
Refactor some parser.t line number tests

The check() function is designed to check the file set by #line, but
the last half dozen tests have no need to test for that.  (I know
because I wrote them.)  So make a new check_line function that just
checks the line number, and have them use that.
Teach mro code about null array elements

This is part of ticket #119433.

Commit ce0d49f changed AVs to use NULL for nonexistent elements.  The
mro lookup code was not accounting for that, causing Class::Contract’s
tests to crash (and perhaps other modules, too).
toke.c:scan_const: Don’t use PL_bufptr

PL_bufptr is passed in as an argument, yet scan_const was some-
times looking at its argument (start) and sometimes using PL_bufptr
directly.  This is just confusing.