[perl #114070] Fix lines nums after <<foo

The line numbers for operators after a here-doc marker on the same
line were off by the length of the here-doc.

This is because the here-doc parser would artificially increase the
line number as it went, because it was stealing lines out of the
input stream.

Instead, we can record the number of lines in the here-doc, and add it
to the line number the next time we need to increment it.

This also fixes the line numbers after s//<<END/e to the end of the
file, which were off because the line number adjusted by the <<END was
localised to the s///.

Since herelines is visible to inner lexing scopes, the outer lexing
scope can see changes made by the inner one.

The lack of localisation does cause problems with line numbers inside
quote-like operators (but they were off by one already), which will be
addressed in subsequent commits.
Stop unterminated here-docs from leaking memory
toke.c: Merge KEY_tr and KEY_y
Stop invalid y/// ranges from leaking
Add PL_parser->lex_shared struct; move herelines into it

PL_parser->herelines needs to be visible to inner lexing scopes, which
also need to have their own copy of it, so that the here-doc parser
can modify the right herelines variable corresponding to the
PL_linestr from which it is stealing its body.  (A subsequent commit
will take take of that.)
op.c: newSTATEOP: don’t check PL_parser after using it

If it is null, we would already have crashed when reaching this
statement.
Fix line numbers inside here-docs

A previous commit put the number of lines in a here-doc in a separ-
ate parser field, which was added on to the line number at the next
CopLINE_inc (actually COPLINE_INC_WITH_HERELINES, now used through-
out toke.c).

Code interpolated inside the here-doc was picking up that value,
throwing line numbers off.

Before that, they were already off by one.

This commit fixes both.

I removed the CLINE from S_scan_heredoc and stopped using TERM (which
uses CLINE) for here-docs.  CLINE sets PL_copline, which is used to
pass a specific line number to newSTATEOP, which may or may not be the
same number as CopLINE(PL_curcop).  newSTATEOP grabs that number and
sets PL_copline to -1 (aka NOLINE).  I assume this was used to make
the statement containing the <<foo marker have the right line number.
But it didn’t fully work out, as subsequent statements on the same
line had the wrong number.  That I fixed a few commits ago when I
introduced herelines, making CopLINE(PL_curcop) have the right line
number for that line.  So the CLINE is not actually necessary anymore.
It was causing a problem also with the first statement inside the
heredoc (in ${...}), which would ‘steal’ the line number of the
<<foo marker.

This also means that <FH> and <.*> no longer do CLINE, but it is not
necessary, as they cannot span multiple lines.
parser.h: Document copline with more detail

It took me a while to figure this out, so here it is for
future readers.
Revert "smoke-me diag"

This reverts commit 372a31d8f53707bcfa9c233ce02a93f778b7bb4b.

I missed this when I was merging that branch.  It should never have
made its way into blead.  It was to find out why the Windows smokes
were temporarily failing, by dumping Config_heavy.pl in the logs.
This was what led to 0ee364945bd.
Fix eval 'q;;'

The parser expects a semicolon at the end of every statement, so the
lexer provides one.  It was not doing so for evals ending with a
semicolon, even if that semicolon was not a statement-terminating
semicolon.
Stop (caller $n)[6] from including final "\n;"

String eval appends "\n;" to the string before evaluating it.
(caller $n)[6], which returns the text of the eval, was giving the
modified string, rather than the original.

In fact, it was returning the actual string buffer that the parser
uses.  This commit changes it to create a new mortal SV from that
string buffer, but without the last two characters.

It unfortunately breaks this JAPH:

eval'BEGIN{${\(caller 2)[6]}=~y< !"$()+\-145=ACHMT^acfhinrsty{}>
<nlrhta"o Pe e,\nkrcrJ uthspeia">}say if+chr(1) -int"145"!=${^MATCH}'
Stop here-docs from gutting (caller $n)[6]

(caller $n)[6] returns the text of the eval.  Actually, it would
return, not the text of the eval, but the text with all the here-doc
bodies missing.

In this commit, I’m abusing the SvSCREAM flag to indicate that the
eval text stored in the context stack is refcounted.