bug#49944: parse-partial-sexp fails to signal an error when (> START LIMIT).

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

>> > We definitely have a bug here.  The documentation in the elisp manual
>> > says that the scanning is done "starting at START".  You're saying it's
>> > perfectly OK to start scanning at "LIMIT"?  This violates the doc.
>> 
>> This is what all function like this say.  To take patient zero --
>> narrow-to-region:
>> 
>> ---
>> When calling from Lisp, pass two arguments START and END:
>> positions (integers or markers) bounding the text that should
>> remain visible.
>> ---
>> 
>> Nothing here about allowing END to come before START, but it does allow
>> that, and so do most (all?) similar commands.
>
> Indeed, if the results are predictable, I see no reason not to support
> START and END in any order, as we do in many places.

I think the case of `parse-partial-sexp` is different because it
receives the argument OLDSTATE which provides the parser's state which
should apply at START.  If START and END are swapped you'll generally
get an incorrect result.

So, I don't care if we signal an error when START > END or if we "do
nothing" (as is customary in some language's `for` loops), but we should
always consider that OLDSTATE is the state that belongs with START and
hence we can't start parsing at END towards START because we don't know
what parsing state to use at END.


        Stefan