toke.c: Remove dead code handling <FH> //

A few lines of code added by this commit:

commit 6f33ba736d46c2f5bfdb2405fd09d82ec18a1d07
Author: Rafael Garcia-Suarez <rgarciasuarez@gmail.com>
Date:   Sun Aug 25 18:42:46 2002 +0000

    Fix parsing problems with the // operator.
    Make // able to follow various unary operators used without
    arguments or parens (shift, pop, getc, pos, readline,
    readlink, undef, umask, and the filetest operators), as
    well as the <FH> operator.

were already unreachable when they were added, specifically the code
for handling // after <FH> (which is fortunate, because XTERMORDORDOR
after <FH> would break <FH>+1).

S_scan_inputsymbol sets pl_yylval.ival to OP_NULL, since it has
already created the ops; it has done so since perl 5.000.  So this
branch is never reached when parsing <FH>.

The if-block containing these lines has had ‘|| op_type ==
OP_READLINE’ since perl 5.000, which has also always been redundant
for the same reason.
Stop lexical CORE sub from interfering with CORE::

The way CORE:: was handled in the lexer was convoluted.

CORE was treated initially as a keyword, with exceptions in the lexer
to make it behave correctly.  If it turned out not to be followed
by ::, then the lexer would fall back to treating it as a bareword
or sub name.

Before even checking for a keyword, the lexer looks for :: and goes
to the bareword/sub code.  But it made a special exception there
for CORE::.

In the end, treating CORE as a keyword recognized by the keyword()
function requires more special cases than simply special-casing CORE::
in toke.c.

This fixes the lexical CORE sub bug, while reducing the total num-
ber of lines.
Make _charnames comparison null-safe

This comparison in toke.c checks whether the charnames translators is
the core’s own and, if so, skips certain validation checks.

Charnames translators coming from any package beginning with
"_charnames\0" would also be exempt from the checks, because the name
comparison stopped at the first null.
Warn for all uses of %hash{...} in scalar cx

and reword the warning slightly.

See <20131027204944.20489.qmail@lists-nntp.develooper.com>.

To avoid getting a warning about scalar context for ‘delete %a[1,2]’,
which dies anyway, I stopped scalar context from being applied to
delete’s argument.  Scalar context is not meaningful here anyway, and
the context is not really scalar.

This also means that ‘delete sort’ no longer produces a warning about
scalar context before dying, so I added a test for that.
POD-only mention sv_setsv does get magic but not set magic
Consistent spaces after dots in sv.c apidocs
Long verbatim pod line in INSTALL