Overhaul the top sections of the class reference (Physics classes)

[MewPurPur]

The top sections of classes are often one of the first things users read about them, so they are important to get right.

Part of a series; this is the one dedicated to the physics team.

In this PR I touched up a lot of short descriptions and major sections of the main descriptions with a "Talk less, say more" ideology. I also tweaked a little bit of documentation to the side and added descriptions to some classes.

Rules for brief descriptions

I'm abiding by a set of rules for consistency. I had them in mind when writing all descriptions, but violated them intentionally sometimes.

• Use the articles "a" and "an". This is helpful for words that can be multiple things, i.e. "light" which can be a noun, an adjective, and a verb. This, and the fact it's grammatically correct, helps with reading comprehension in many cases.

• Use a single sentence with punctuation. If two sentences are needed, don't use newline.

• Never use text formatting (i.e. italics) or external links.

• Don't use capitalization for normal words. If referring to a class, use a reference.

• For nodes, always answer "What is this?". For non-node objects, it's also OK to answer "What does this do?"

• Avoid self-referencing, such as "Popup: Popup is a [...]"

• Avoid circular reasoning such as "CanvasLayer: Canvas drawing layer."

  • Exception 1: It's something common folk are familiar with, i.e. "Timer: A countdown timer."
  • Exception 2: The class can't be used by people who don't know the term, i.e. it's okay to say "XML" in XMLParser.

• When a class is abstract, start with "Abstract base class for [...]".

• I often used "Holds X" and "Stores X" to replace "Contains X" - I think it improves clarity that X is the main thing, not just one of the things the resource holds.

• Try to stay under 120 characters without comprimising the quality of writing. (Sometimes it's impossible, in that case, go on for a bit longer)

Thanks a ton to Estel and smix8 who helped with and reviewed some of these changes in advance.

[smix8]

Only checked the technical correctness for the NavigationServer related classes. Some had already outdated descriptions before and should be corrected now.

Not in this pr but at some later point this needs a more in-detail overhaul to make it really easier to grasp for beginners and remove all that unhelpful noise from the descriptions. Especially the AStar classes are difficult to stomach for beginners. Half their descriptions read like if the association of mathematicians had a field day. They are not wrong, just overly convoluted with special vocabulary.

[smix8]

For the navigation part looks good for the scope of this pr.

[Calinou]

Descriptions look good to me. See #76526 (review) about the "A"/"An" discussion, which applies to this PR as well.

[mhilbrunner]

See discussion about A/An, otherwise looks good to me. :)

[YuriSizov]

Thanks!