Overhaul the top sections of the class reference (Core 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.

After I recently fixed Quaternion's description (which was "Quaternion.") I thought it would be a good idea to nip in the bud any need for such corrections in the near future. After all, Node2D still thinks it holds the Z-index property, some GPU Particles' colliders think they are attractors, the 2D world boundary thinks it's a plane, and what's "law of cosigns"? And so, SO many descriptions are circular - I get that a PinJoint2D is "A pin joint for 2D", but what is it?

^ I'm already working on more PRs that will address all the issues raised above - this is just the one dedicated to the core team.

I mostly touched up the short descriptions and occasionally the full descriptions and the tutorials sections. But I also overhauled bool's documentation and tweaked and filled up a little bit of documentation to the side.
StreamPeerExtension remains undocumented. KoBeWi took care of documenting PackedDataContainer (finally!). I also wrote documentation for WorkerThreadPool, but I separated it.

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 compromising the quality of writing. (Sometimes it's impossible, in that case, go on for a bit longer)

A long list of brief description changes

Classes not on here are ones I thought to be already excellent, or ones that I didn't realize were "core". This list might be a slightly outdated (like, by 1%).

@GDscript: Built-in GDScript constants and functions.
AABB: A 3D axis-aligned bounding box.
AESContext: Provides functionality for AES encryption/decryption of raw data.
Array: A built-in data structure that stores a sequence of elements.
Basis: A 3×3 matrix for representing 3D rotation and scale.
ClassDB: A class information repository.
Crypto: Provides access to advanced cryptographic functionalities.
bool: A built-in boolean type.
Callable: A built-in type representing a method or a standalone function.
Color: A color represented in RGBA format.
Dictionary: A built-in data structure that stores key-value pairs.
DirAccess: Provides methods for managing directories and their content.
Engine: Provides access to engine properties.
FileAccess: Provides reading and writing operations for files.
float: A built-in type for a floating point numbers.
Geometry2D: Provides methods for some common 2D geometric operations.
Geometry3D: Provides methods for some common 3D geometric operations.
HashingContext: Provides functionality for computing cryptographic hashes chunk by chunk.
Input: A singleton for handling inputs.
InputEvent: Abstract base class for input events.
InputEventFromWindow: Abstract base class for [Viewport]-based input events.
InputEventGesture: Abstract base class for touch gestures.
InputEventJoypadButton: Represents a button on a gamepad being pressed or released.
InputEventJoypadMotion: Represents axis motions (such as joystick or analog triggers) from a gamepad.
InputEventKey: Represents a key on a keyboard being pressed or released.
InputEventMagnifyGesture: Represents a magnifying touch gesture.
InputEventMIDI: Represents an input event from a MIDI device, such as a piano.
InputEventMouse: Abstract base class for mouse input events.
InputEventMouseButton: Represents a mouse button being pressed or released.
InputEventMouseMotion: Represents a mouse movement.
InputEventPanGesture: Represents a panning touch gesture.
InputEventScreenDrag: Represents a screen drag event.
InputEventScreenTouch: Represents a screen touch event. {Remove outdated note}
InputEventWithModifiers: Abstract base class for input events affected by modifier keys like [code]Shift[/code] and [code]Alt[/code].
InputEventShortcut: Represents a triggered keyboard [Shortcut].
InputMap: A singleton that manages all [InputEventAction]s.
int: A built-in type for integers.
Mutex: A binary [Semaphore] for synchronization of multiple [Thread]s.
MissingNode: An internal editor class intended for keeping the data of unrecognized nodes.
MissingResource: An internal editor class intended for keeping the data of unrecognized resources.
Node: Base class for all scene objects.
NodePath: A pre-parsed scene tree path.
Object: Base class for all other classes in the engine.
OS: Provides access to common operating system functionalities.
PackedDataContainer
PackedDataContainerRef: A reference-counted [PackedDataContainer].
Plane: A plane in Hessian normal form.
Projection: A 4×4 matrix for 3D projective transformations.
ProjectSettings: Stores globally-accessible variables.
RandomNumberGenerator: Provides methods for generating pseudo-random numbers.
Rect2: A 2D axis-aligned bounding box using floating-point coordinates.
Rect2i: A 2D axis-aligned bounding box using integer coordinates.
ResourceLoader: A singleton for loading resource files.
ResourcePreloader: A node used to preload sub-resources inside a scene.
ResourceSaver: A singleton for saving [Resource]s to the filesystem. {FIX DESC}
RID: A handle for a [Resource]'s unique ID.
SceneState: Provides access to a scene file's information. {It can not be used to change the state, only to access it. Often used to peek into what a [PackedScene] contains without instantiating it.}
Semaphore: A synchronization mechanism used to control access to a shared resource by [Thread]s. {Add thread-safe APIs.}
Signal: A built-in type representing a signal defined in an [Object].
StreamPeer: Abstract base class for interacting with streams.
StreamPeerBuffer: A stream peer that handles binary data streams.
StreamPeerGZIP: A stream peer that handles GZIP and deflate compression/decompression.
StreamPeerTCP: A stream peer that handles TCP connections.
StreamPeerTLS: A stream peer that handles TLS connections.
**String: ** A built-in type for strings.
StringName: A built-in type for unique strings.
Thread: A thread used for simultaneous execution of code. {Allows to offload work from the [MainLoop].}
Time: A singleton for working with time data.
Transform2D: A 2×3 matrix representing a 2D transformation.
Transform3D: A 3×4 matrix representing a 3D transformation.
Vector2: A 2D vector using floating point coordinates.
Vector2i: A 2D vector using integer coordinates.
Vector3: A 3D vector using floating point coordinates.
Vector3i: A 3D vector using integer coordinates.
Vector4: A 4D vector using floating point coordinates.
Vector4i: A 4D vector using integer coordinates.
WeakRef: Holds an [Object]. If the object is [RefCounted], it doesn't update the reference count.
World2D: A resource that holds all components of a 2D world, such as a canvas and a physics space.
World3D: A resource that holds all components of a 3D world, such as a visual scenario and a physics space.

Thank you to the many people that helped with and reviewed some of these changes in advance: Winston, KoBeWi, SlugFiller, Estel, and others.

[MewPurPur]

Being an Espeon, I saw the future and noticed that #76527 was going to be released right after my PR. So I removed this note prematurely.

(On a serious note, I removed it because the top section is not the place, and with that PR now up, this will likely be optimized soon, so this doesn't concern users. Performance hints should be used for more timeless things, like "Concave collision shapes are the slowest" and "Shapecasts are slower than raycasts"

[Calinou]

New descriptions look good to me.

My only concern is about whether brief descriptions should start with "A"/"An", or whether we should skip it for brevity.

[mhilbrunner]

I'm in favor of skipping A/An at the beginning of the short description.

[mhilbrunner]

See note about A/An, otherwise LGTM.

[MewPurPur]

I did this initially as I was also in favor of dropping A/An, but after going through hundreds of classes, I found many situations where it was significantly worse.

• It's grammatically incorrect, less professional.
• It makes it harder to parse that a word is a noun. Consider this old description - "Type to handle file reading and writing operations." - it's totally ambiguous, one might think this is an input field where you can type commands for file access. There are a lot of words in English that can be nouns, adjectives, and verbs simultaneously, and it's not reasonable to try to avoid them.
• It makes it harder to parse whether an object is unique. For example, "Eevee that pushes stuff off the table" leaves it unclear whether this is "The Eevee" responsible for this task (e.g. a singleton) or just an Eevee you can instantiate a lot of to push more things off the table. A/An are the shortest way to avoid this ambiguity.

All for 2-3 characters. I don't think it's worth it. I'm very against doing this, I would prefer to discuss it separately from these PRs.

(it's also why I've put it front and center in my unofficial "rulebook for brief descriptions")

[YuriSizov]

Good call. Thanks a bunch!

[YuriSizov]

Cherry-picked for 4.0.4. I skipped changes to the multithreading classes because they depend on #72249, which is unlikely to be cherry-picked (or will be picked later).