This PR represents a set of tweaks to the project documentation, mostly focused around usability and presentation of information. A lot of it is obviously subjective, and while I personally thing each change is an improvement, I'm not married to any of it and am more than willing to take feedback / remove anything that's not wanted. It's all in very granular commits specifically so that it can easily be adjusted.

What's here

(Formatted as a checklist, so we can mark off anything to be removed/changed)

• Turned all of the 3.0.0 "Deprecated" messages into real .. deprecated:: markup
• Added .. versionchanged:: and .. versionadded:: markup for most of the items in the "what's new in 3.1.0 / 3.2.0" documents (some items don't easily translate into API documentation)
• Added custom CSS to style the change messages for visibility. It makes use of the relatively-new CSS :has() selector to push the .. deprecated:: styling up to the containing class/function/method/etc. level, so that anything marked deprecated has a red border line running all the way down its left side for maximum visibility. You'll see in screenshots.
  (After some deliberation, I decided not to do the same with added/changed notes, because those won't be "recent" forever and as they age they deserve less prominence. Deprecated features warrant greater prominence, if anything, as time passes until they're eventually removed.)
• Eliminated the unnecessary docs/modules.rst document, and made docs/pyparsing.rst the top-level index for its own documentation (by putting a hidden .. toctree:: at the bottom containing only self).
• Moved the documentation from a couple of classes' __init__s to the class itself, and removed the __init__ signatures from the docs entirely, since the construction signatures are shown on the class itself and the __init__s become totally redundant, with the documentation moved.
• Removed the .. sectnum::s from the documentation pages, because Sphinx says not to use them, and with good reason -- they're totally broken. Every document gets numbered "1" in the TOC. There are apparently ways to make the sections properly numbered, but sectnum isn't it. (I personally don't think it's necessary.)

Sphinx configuration changes

• Leave class/module parents out of the TOC, for readability and to keep them from overflowing into the body text
• Break longer call signatures (over 100 characters, as currently configured) at each argument for "better" readability; it's still not great but better than one long, sometimes-four-or-five-wrapped-lines continuous signature string.
• Leave resolvable type names unexpanded in the signatures, which affects some signatures in small ways. (For example, the default max_matches argument for ParserElement.scan_string() is now listed as _MAX_INT instead of 9223372036854775807.)

autodoc configuration changes

• I changed the .. automodule:: in pyparsing.rst like so:

Before

.. automodule:: pyparsing
    :members:
    :special-members:
    :show-inheritance:

After

.. automodule:: pyparsing
    :members:
    :undoc-members:
    :special-members: __add__,__sub__,__div__,__mul__,__and__,__or__,__xor__,__call__,__weakref__,__str__
    :exclude-members: __init__,__repl__,parseImpl,parseImpl_regex,parseImplAsGroupList,parseImplAsMatch,postParse,preParse
    :show-inheritance:

Which, obviously, greatly affects the contents of the documentation. But I felt there were a number of undocumented members that were worth showing signatures for, and many special members that weren't, so explictly selecting the ones we actually want seemed more productive.

It is a lot of configuration, though, and isn't maintenance-free. (For example, after I added a .. versionchanged:: to the __str__ method for ParseBaseException, I had to go back and add __str__ to the :special-members: list to get it to show up in the docs.)

So, even more than everything else, explicitly up for debate / open to revision.

I'll follow up with comment(s) showing some side-by-side screenshots, this opening message has gotten long enough.