heredoc.t: Add a CRLF test

I nearly broke this in recent bug fixes
toke.c: -DT should report forced tokens under -Dmad

I was wondering why the -DT output was missing things out.
This is why:

#ifdef PERL_MAD
	    /* FIXME - can these be merged?  */
	    return next_type;
#else
	    return REPORT(next_type);
#endif
Devel::Peek: Fix so compiles under C++

Commit 86b9d29366aea0e71ad75b61d04f56f1fe5b0d4d created a new PADLIST
type.  However, this broke the compilation of Devel::Peek with C++.
This commit gets it to compile again, and pass our regression test
suite.

[Modified by the committer to use the correct PADLIST_ macros; other-
 wise it will crash.]
Peek.t: Test that DeadCode doesn’t crash

I broke it, but Karl Williamson’s commit (the previous) with my tweaks
fixes it.  This function was not at all exercised by the test suite.
[perl #114040] Fix here-docs in multiline re-evals

Commit 5097bf9b8 only partially fixed this, or, rather, did the
groundwork for fixing it.

If we have a pattern like this:

/(?{<<foo . baz
bar
foo
})/

Then PL_linestr contains this while we are parsing the block:

"(?{<<foo . baz\nbar\nfoo\n})"

The code for parsing a here-doc in a multiline PL_linestr buffer
(which applies to here-docs in string evals or in quote-like operat-
ors) likes to modify PL_linestr to contain everything after the
<<heredoc marker except the here-doc body, which has been stolen (but
it oddly includes the last character of the marker, which does not
matter, as PL_bufptr is set to PL_linestart+1):

"o . baz\n})"

The regexp block parsing code expects to be able to extract the entire
block (as a string) from PL_linestr after parsing it.  So it is not
helpful for S_scan_heredoc to go and modify it like that.

Before modifying PL_linestr, we can set aside a copy of the source
code (in PL_sublex_info.re_eval_str) from the beginning of the regexp
block to the end of PL_linestr, so that the regexp block code can
retrieve the original source from there.

We also adjust PL_sublex_info.re_eval_start so that at the end of the
regexp block PL_bufptr - PL_sublex_info.re_eval_start is the length of
the block.

Instead of clobbering PL_linestr, we can copy everything after the
here-doc to when the body begins.  And this for two reasons: it
requires less allocation (I would have made that change in the end
anyway, for efficiency), and it makes it easier to calculate how much
to subtract from re_eval_start.

This fix does not apply to here-docs in quotes in multiline string
evals, which crashes and always has.
PATCH: Devel::Peek doesn't compile under C++

Commit c9795579db61c900bacee2790bdceb7bad3dd45d introduced
an error in C++: it's missing a cast.
toke.c: Extreme paranoia
pad.[ch]: PADNAME_OUTER

I think this is the last bit of pad-as-sv stuff that was not
abstracted away in pad-specific macros.
pad.h: PADNAME_SV

If CPAN modules should not assume that pad names are SVs, we need
to provide a better way than newSVpvn(PADNAME_PV(pn),PADNAME_LEN(pn))
to get an SV out of it, as, knowing that pad names are just SVs, the
core can do it more efficiently by simply returning the pad name
itself.
pad.h: typos in macro definitions

It would help to define these macros properly.
pad.h: Let PADNAME_PV return null
B::Deparse: Suppress trailing ; in formats

While it doesn’t change the behaviour, nobody writes formats that way,
and this makes the output match 5.17.2 and earlier.
Increase $B::Deparse::VERSION to 1.17
Use FooBAR convention for new pad macros

After a while, I realised that it can be confusing for PAD_ARRAY and
PAD_MAX to take a pad argument, but for PAD_SV to take a number and
PAD_SET_CUR a padlist.

I was copying the HEK_KEY convention, which was probably a bad idea.
This is what we use elsewhere:

   TypeMACRO
   ----=====
     AvMAX
    CopFILE
   PmopSTASH
  StashHANDLER
 OpslabREFCNT_dec

Furthermore, heks are not part of the API, so what convention they use
is not so important.

So these:

    PADNAMELIST_*
    PADLIST_*
    PADNAME_*
    PAD_*

are now:

    Padnamelist*
    Padlist*
    Padname*
    Pad*
pad.h: PadnameSTATE
Fix the version of Scalar::Util in corelist for 5.7.3
Clean up data for Carp::Heavy in Module::CoreList

It was lagging behind by about one release -- presumably due to it being
based on $Carp::VERSION.
Clean up data for Pod::Perldoc::ToTk in Module:CoreList

It was alternating between 'undef' and undef.
Clean up data for ExtUtils::Miniperl in Module::CoreList

Some corelist data was constructed without ExtUtils::Miniperl being
present, presumably because perl wasn't fully built at the time.