toke.c: Change S_scan_str parameter meaning

The 'keep_bracketed' parameter is used to tell this static function to
not delete the escaping backslash if the string's delimiter character is
also found within the interior of the string.

This parameter is always currently false, except when compiled with
PERL_MAD.  However it has been Okayed to remove this compilation option,
so the parameter can be changed to whatever is desired.

A future commit will change this parameter to be true sometimes.  In
doing so, it sets up a conflict with the fairly new 're_reparse'
parameter (this conflict also exists with PERL_MAD, but clearly nobody
has tried to compile it that way for a while)

However the new conflict only happens when the opening delimiter of the
string is the same as the closing one, and happily the new commits only
need to have this parameter be true when the opening and closing are
different, so things can be set up so that there is actually no
conflict, given that MAD is being removed.

At the time that scan_str is called, what the delimiters are is not
necessarily known, so this commit refactors the meaning of the parameter
to be TRUE iff the delimiters that scan_str finds actually differ.  It
renames the parameter to indicate this.
Deprecate unescaped literal "{" in regex patterns

This commit also causes escaped (by a backslash) "(", "[", and "{" to be
considered literally.  In the previous 2 Perl versions, the escaping was
ignored, and a (default-on) deprecation warning was raised.  Now that we
have warned for 2 release cycles, we can change the meaning.of escaping
to actually do something

Warning when a literal left brace is not escaped by a backslash, will
allow us to eventually use this character in more contexts as being
meta, allowing us to extend the language.  For example, the lower limit
of a quantifier could be omited, and better error checking instituted,
or things like \w could be followed by a {...} indicating some special
word character, like \w{Greek} to restrict to just Greek word
characters.

We tried to do this in v5.16, and many CPAN modules changed to backslash
their left braces at that time.  However we had to back out that change
before 5.16 shipped because it turned out that escaping a left brace in
some contexts didn't work, namely when the brace would normally be a
metacharacter (for example surrounding a quantifier), and the pattern
delimiters were { }.  Instead we raised the useless backslash warning
mentioned above, which has now been there for the requisite 2 cycles.

This patch partially reverts 2 patches.  The first,
e62d0b1335a7959680be5f7e56910067d6f33c1f, partially reverted
the deprecation of unescaped literal left brace.  The other,
4d68ffa0f7f345bc1ae6751744518ba4bc3859bd, instituted the deprecation of
the useless left-characters.

Note that, as in the original attempt to deprecate,  we don't raise a
warning if the left brace is the first character in the pattern.  This
is because in that position it can't be a metacharacter, so we don't
require any disambiguation, and we found that if we did raise an error,
there were quite a few places where this occurred.