CvGV is no longer a simple struct member access

The same slot is also used for the NAME_HEK for lexical subs, so:

- split B::CV::GV out into its own function that uses the CvGV macro

- add B::CV::NAME_HEK so the name of a lexical sub can be fetched
[perl #118525] make it work on threaded builds

(cherry picked from commit 5016d3c45a66ce5b279c253e8a8c2a38a9bd8431)
Handle /[#]/ and /[(?#]/ with code blocks

This is a regression in 5.18.0.

In something like /[#](?{})/x, the perl toker incorrectly sees the '#' as a
comment and skips the code block without parsing it.

(cherry picked from commit c30fc27b4df65a43710b25dd1d2a57d78ee2fe33)
Don’t leak the /(?[])/ parsing stack on error

Instead of creating the parsing stack and then freeing it after pars-
ing the (?[...]) construct (leaking it whenever one of the various
errors scattered throughout the parsing code occurs), mortalise it to
begin with and let the mortals stack take care of it.

(cherry picked from commit 1e4f088863436a8019c7d864691903ffdafeefda)
Stop (?[]) operators from leaking

When a (?[]) extended charclass is compiled, the various operands are
stored as inversion lists in separate SVs and then combined together
into new inversion lists.  The functions that take care of combining
inversion lists only ever free one operand, and sometimes free none.
Most of the operators in (?[]) were trusting the invlist functions to
free everything that was no longer needed, causing (?[]) compilation
to leak invlists.

(cherry picked from commit a84e671a269f736a404a62f21caacc8a431c2aca)
Stop /(?[\p{...}])/ compilation from leaking

The swash returned by utf8_heavy.pl was not being freed in the code
path to handle returning character classes to the (?[...]) parser
(when ret_invlist is true).

(cherry picked from commit c80d037c54749655d40eac068936c5222ce9d8ee)
Free operand when encountering unmatched ')' in (?[])

I only need to free the operand (current), not the left-paren token
that turns out not to be a paren (lparen).

For lparen to leak, there would have to be two operands in a row on
the charclass parsing stack, which currently never happens.

(cherry picked from commit 4bc5d08976b7df23b63a56cc017a20ac5766fbbc)
Don’t leak when compiling /(?[\d\d])/

The ‘Operand with no preceding operator’ error was leaking the last
two operands.

(cherry picked from commit b573e7000fd9c1cfae30ae5fb328a25b9bf3870a)
perldelta: add a missing "=" from a Pod directive
perldelta: the easy pre-editing before final checks
perldelta: Digest::SHA fix in 79fe145
perldelta: hints updates from 4b985f1 and 9de5f95
perldelta: perldelta for /[#]/ and /(?[...])/ changes
perldelta: remove sections we will not need
perlhist: import the latest perlhist from blead
version bump, because Digest::SHA changed
import Module-Corelist 2.95 from blead
update corelist with v5.18.1 changes

I am not following the instructions in the RMG, because the
procedure is sort of a mess.  I will make sure that blead gets into
the right state when this is done.  In the meantime, doing it this
way should require less weird moving of work back and forth.
bump version to v5.18.1-RC1
Update META.json for RC1