reg_mesg.t: Turn off regexp warns along with deprecated

Some warnings are both regexp and deprecated.  To test that they are
under control of 'deprecated', it is necessary to turn off both
categories.  We currently don't test that they are also under 'regexp'
control
PATCH: [perl #117327]: Sequence (?#...) not recognized in regex

This reverts commit 504858073fe16afb61d66a8b6748851780e51432, which
was made under the erroneous belief that certain code was unreachable.
This code appears to be reachable, however, only if the input has
a 2-character lexical token split by space or a comment.  The token
should be indivisible, and was accepted only through an accident of
implementation.  A later commit will deprecate splitting it, with the
view of eventually making splitting it a fatal error.  In the meantime,
though, this reverts to the original behavior, and adds a (temporary)
test to verify that.
lib/utf8_heavy.pl: Fix separated '(?' token

The next commit will warn when these aren't adjacent
Deprecate spaces/comments in some regex tokens

This commit deprecates having space/comments between the first two
characters of regular expression forms '(*VERB:ARG)' and '(?...)'.
That is, the '(' should be immediately be followed by the '*' or '?'.
Previously, things like:

   qr/((?# This is a comment in the middle of a token)?:foo)/

were silently accepted.

The problem is that during regex parsing, the '(' is seen, and the input
pointer advanced, skipping comments and, under /x, white space, without
regard to whether the left parenthesis is part of a bigger token or not.
S_reg() handles the parsing of what comes next in the input, and it
just assumes that the first character it sees is the one that
immediately followed the input parenthesis.

Since the parenthesis may or may not be a part of a bigger token, and
the current structure of handling things, I don't see an elegant way to
fix this.  What I did is flag the single call to S_reg() where this
could be an issue, and have S_reg check for for adjacency if the
parenthesis is part of a bigger token, and if so, warn if not-adjacent.