doc: fix silly confusion about re "strict" (#493)

in Perl, `use strict` has no effect on this feature but instead
the "strict" mode referenced applies to `use re 'strict'`

doc/pcre2compat.3

@@ -228,7 +228,7 @@ handled by PCRE2, either by the interpreter or the JIT. An example is
 .P
 23. From release 10.45, PCRE2 gives an error if \ex is not followed by a 
 hexadecimal digit or a curly bracket. It used to interpret this as the NUL 
-character. Perl still generates NUL, but warns in its warning and strict modes.
+character. Perl still generates NUL, but warns in its warning mode.
 .
 .
 .SH AUTHOR

doc/pcre2pattern.3

@@ -433,7 +433,7 @@ By default, after \ex that is not followed by {, one or two hexadecimal
 digits are read (letters can be in upper or lower case). If the character that
 follows \ex is neither { nor a hexadecimal digit, an error occurs. This is
 different from Perl's default behaviour, which generates a NUL character, but
-is in line with Perl's "strict" behaviour.
+is in line with the behaviour of Perl's 'strict' mode in re.
 .P
 Any number of hexadecimal digits may appear between \ex{ and }. If a character
 other than a hexadecimal digit appears between \ex{ and }, or if there is no

src/pcre2_compile.c

@@ -2060,8 +2060,8 @@ else
         /* Perl has the surprising/broken behaviour that \x without following
         hex digits is treated as an escape for NUL. Their source code laments
         this but keeps it for backwards compatibility. A warning is printed
-        when "use warnings" is enabled, and it's forbidden when "use strict"
-        is enabled. Because we don't have warnings, we simply forbid it. */
+        when "use warnings" is enabled. Because we don't have warnings, we
+        simply forbid it. */
         if (ptr >= ptrend || (cc = XDIGIT(*ptr)) == 0xff)
           {
           /* Not a hex digit */
@@ -2072,9 +2072,9 @@ else
         c = cc;
 
         /* With "use re 'strict'" Perl actually requires exactly two digits (error
-        for both \xA and \xAAA). This seems overly strict, and there seems
-        little incentive to align with that, given the backwards-compatibility
-        cost.
+        for \x, \xA and \xAAA). While \x was already rejected, this seems overly
+        strict, and there seems little incentive to align with that, given the
+        backwards-compatibility cost.
 
         For comparison, note that other engines disagree. For example:
           - Java allows 1 or 2 hex digits. Error if 0 digits. No error if >2 digits