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)