toke.c:scan_heredoc: less pointer fiddling; one less SV

toke.c:scan_heredoc: less pointer fiddling; one less SV

The loop for reading lines of input to find the end of a here-doc has
always checked to see whether the cursor (s) was at the end of the
current buffer:

    while (s >= PL_bufend) {	/* multiple line string? */

(Actually, when it was added in perl 3.000, it was in scanstr and
that loop was not specific to here-docs, but also applied to multi-
line strings.)

The code inside the loop ends up fiddling with s by setting it explic-
itly to the end of the buffer or the end of the here-doc marker, minus
one to make sure it does not coincide with the end of the buffer.

This doesn’t make any sense, and it makes the rest of this function
more complicated.

Because the loop used to be outside the else block, it was also
reached for a here-doc inside a string eval, but the code for that
ensured the condition for the while loop was never true.

Since the while loop set s to one less than it needed to be set to,
in order to break out of it, it had to have s++ just after the loop.
That s++ was reached also by the eval code, which, consequently, had
to adjust its value of s.

That adjustment actually took place farther up in the function, where
the herewas SV was assigned to.  (herewas contains the text after the
here-doc marker to the end of the line.)  The beginning of herewas
would point to the last character of the here-doc marker inside an
eval, so that subtracting SvCUR(herewas) from the buffer end would
result in an adjusted pointer.

herewas is currently not actually used, except for the length.  Until
recently, the text inside it would be copied back into PL_linestr to
recreate where the lexer needed to continue (because PL_linestr was
being clobbered).  That no longer happens.

So we can get rid of herewas altogether.  Since it is in an else
block, the stream-based parser does not need to fiddle pointers to
exit the loop.  It can just break explicitly.  So the s++ can also
go, requiring changes (and simplifications) to the eval code.  The
comment about it being a multiline string is irrelevant and can go,
too.  It dates from when that line was actually in scanstr and applied
to quoted strings containing line breaks.