Respect #line directives in here-docs

Respect #line directives in here-docs

#line directives in here-docs used to be ignored after the heredoc:

<<END
${
#line 27
print __LINE__,"\n" # prints 27
}
END
; print __LINE__, "\n"; # prints 7

This commit changes that by recording in PL_multi_end the end of
the here-doc (more precisely, the last line of the body, before the
terminator) during the initial parse to find the terminator.  When
the body is parsed for double-quotish stuff, at the very end (in
sublex_done) the last line number is compared with the one recorded.
Any differences are applied to the current ‘herelines’ value, which
records how many line numbers need to be skipped when the line ending
after the here-doc marked (<<END) is reached.

It conflicts with a line number workaround in op.c, which hasn’t done
anything since I accidentally disabled it in 5.18.

Added in 0244c3a40, this code set the current line number to the end
of the here-doc when creating the substitution op for s//<<foo/e.
Before that, since the line number was localised to the lexing scope,
the new line number set by the here-doc would be undone when the s///
finished, throwing off all subsequent line numbers.

Commit 83944c0156 solved the problem of the line number for code after
the here-doc marker having the wrong line number (because the here-doc
parser would increase the line number by the number of lines in the
here-doc body straightaway).  It introduced the ‘herelines’ value,
recording how many lines the here-doc body contained, but without
updating the line number yet, so that code after the <<marker would
have the right line, but the next \n would increment the line number
by herelines+1.  That accidentally stopped PL_multi_end from having
the right value, disabling the line number code in op.c.  But the
other changes rendered that code unnecessary.