bug#81611: 31.0.90; show-paren-mode reports false mismatch

Reproduction:

1. emacs -Q --eval '(with-current-buffer "*scratch*"
  (erase-buffer)
  (emacs-lisp-mode)
  (insert "\"S\" (\";\"\n)")
  (setq blink-matching-paren-distance 9)
  (show-paren-mode 1)
  (goto-char (point-max))
  (message "%S" (show-paren--default)))'
2. Note the mismatch on the last parenthesis.
3. M-x eval-expression RET (show-paren--default) RET

Expected: (10 11 5 6 nil) -- the final ")" correctly matched to the "("
five characters before it.  The buffer is a complete, well-formed pair
of top-level forms (a string "S" followed by the list (";")). Also, the
value of `blink-matching-paren-distance` covers correctly balanced
parenthesis.

Actual: (10 11 nil nil t) -- MISMATCH.

Cause: show-paren--default (paren.el) narrows the buffer to
blink-matching-paren-distance characters around point before calling
scan-sexps backward to find the match.  In the repro above, with
blink-matching-paren-distance = 9, the narrowed buffer start on the "S"
character inside the string.  The parsing then considers the content

,----
| S" (";"
| )
`----

So `S` is not in a string, the " (" is a string, `;"` is a comment and `)` is
mismatched.

Note that repro above is a minimized illustration of a real issue that I
noticed in some elisp files, rather than caused by a deliberately small
`blink-matching-paren-distance`. Even with large
`blink-matching-paren-distance`, any file large enough to trigger the
narrowing (bigger than 2 * blink-matching-paren-distance, i.e. bigger
than ~200,000 characters by default) will eventually have the narrowing
land inside some string purely by coincidence, then if there's any
string with a semicolon in in the narrowed region, parsing will be
misaligned as it is in the repro above.

Suggested fix: Before narrowing, check syntax-ppss at the cutoff; if it
is inside a string or comment, don't cut there -- but snap forward (or
backward) to a position outside strings/comments.

-- Al