We don't use that info for anything, and it generates unnecessary diffs
every time we bump the minor version (and CI failures if we forget to
sync some files from opt-in modules (mono, text_server_fb).
This is a much simpler attempt to solve the same problem as #76060, but without breaking any compatibility.
* Adds a description of what model space is in the Vector3 enums (MODEL_* constants). This has the proper axes laid out for imported 3D assets.
* Adds the option to `look_at` using model_space, which uses Vector3.MODEL_FRONT as forward vector.
The attempt of this PR is to still break the assumption that there is a single direction of forward (which is not the case in Godot)
and make it easier to understand where 3D models are facing, as well as orienting them via look_at.
- Remove `Transform3D(Quaternion, Vector3)` constructor from C#.
- Add `Transform3D(Projection)` constructor to C#.
- Add documentation to the `Transform3D(Projection)` constructor in Core.
- Add `Transform3D` constructor with only real_t params to C# that mirrors `Transform2D`.
- Expose `Basis` constructor with only real_t params in C#.
- Add `Transform2D(real_t, Vector2, real_t, Vector2)` constructor to C#.
Implement built-in classes Vector4, Vector4i and Projection.
* Two versions of Vector4 (float and integer).
* A Projection class, which is a 4x4 matrix specialized in projection types.
These types have been requested for a long time, but given they were very corner case they were not added before.
Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity.
**Q**: Why Projection and not Matrix4?
**A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
This makes it easier to spot syntax errors when editing the
class reference. The schema is referenced locally so validation
can still work offline.
Each class XML's schema conformance is also checked on GitHub Actions.
Notably:
* `Packed*Array.size()` and `Array.size()`.
* Shared methods of `Transform2D` and `Transform3D`.
* Shared methods of `Vector2`, `Vector3`, and `Vector2i`.
This reduces the Deja Vu when translating the class reference :)
For the time being we don't support writing a description for those, preferring
having all details in the method's description.
Using self-closing tags saves half the lines, and prevents contributors from
thinking that they should write the argument or return documentation there.
