bug#56682: Fix the long lines font locking related slowdowns

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> Try `M-: (use-global-map (make-keymap)) RET`
>> Should we prevent users from doing that?
> It's a misleading question.  No "user" would ever do that.  Sure, it's
> a nice example, but only an Elisp hacker would do that, in the middle of
> a debugging session, and they would do that on purpose (although perhaps
> without knowing the effect in advance).  Which has nothing to do with
> a regular user who just opens a file.

FWIW, the above is my standard example because I ended up doing exactly
that by accident, locking myself out of the session I was trying to
debug, so in a sense, I'd have been happy (that one time) if Emacs had
prevented me from doing it.

>> Let's focus on making it easy to make it work well, rather than making it
>> impossible to make it work poorly.
> You lost me here.  I've read that sentence twenty times, and cannot
> understand what you mean.

Your current code makes it impossible for a major mode to make Emacs
slow by widening in a too-long-line.  I'd prefer if we made it easy
(i.e. the default) for Emacs to work well in that case, without making
it impossible for the major mode to mess things up.

E.g. use narrowing (and arrange for the known widening culprit to be
disabled) so that the default behavior is sane, but sllow an ELisp
package from re-widening (possibly using a specific call to do that) if
it thinks it's a good idea (even if it may turn out not to be so).

> But if you use heuristics, as I said, you don't need to look at all the
> chars between BOB and POS.  You try your best to guess, on a small (a few
> kilobytes) portion of the buffer, where the strings most likely start and
> stop.  And if you're only right in 95% of the cases, that's more than fine.

For specific languages, you can use various heuristics to guess which
quotes start and which quotes end a string (for some languages you can
even do it reliably), but `syntax-ppss` handles all kinds of languages
(and doesn't have access to such heuristics currently), such as ELisp
where it's hard to do it well.

I'd prefer to first see concrete examples where speeding up the
"syntax-ppss in a 1GB buffer" would make a significant difference to the
end-user's experience.  Then we can think about what's the better way to
solve the problem (which may be to just give up on font-lock altogether,
or maybe to refine the `syntax.el` code (maybe move some of it to C), or
to speed up `parse-partial-sexp`, or maybe let major modes provide
those heuristics to find a "safe point" again (these used to exist, see
`syntax-begin-function`, for example, but they tended to suck)).


        Stefan