Presort text draw calls.

[bruvzg]

Pre-sort text draw calls to improve batching, should significantly reduce draw call number for languages with a lot of glyphs and multiline text with outlines/shadow.

Before:

After:

Fixes #107109
Fixes #104537

[bruvzg]

Some extra tests:

1. Label with CJK test using system font fallback.

4.5 beta 3 - FPS: 330, draw calls 967
this PR - FPS: 1980, draw calls 14

2. Label with Latin text.

4.5 beta 3 - FPS: 1570, draw calls 50
this PR - FPS: 1740, draw calls 2
(as expected, much lower difference)

3. RTL with CJK text:

4.5 beta 3 - FPS: 315, draw calls 980
this PR - FPS: 2080, draw calls 15

4. BBCode demo:

4.5 beta 3 - FPS: 145, draw calls 45
this PR - FPS: 145, draw calls 23
(FPS seems to be linited by constant redraws of the RTL, not number draw calls)

5. 500 random Labels with outline.

4.5 beta 3 - FPS: 380, draw calls 1000
this PR - FPS: 380, draw calls 1000
(can't be batched, labels are different canvas items and have specific draw order)

Compatibility break actually fixes an incorrect earlier definition.

[Mickeon]

Given how fairly important batching text calls seems to be, the class reference is a bit lacking in recommendations on how to make use of the API introduced in this PR.

[Mickeon]

This can be seen as huge nitpick but I had to get it off of my chest someday.

All of these very brief descriptions in the TextServer may seem good at a glance, but they're quite unwelcoming. Hard to parse, difficult to localize, devoid of information. Yes, as an experienced developer with decent English knowledge, it's reasonably easy to understand what each parameter does, but that's not every one. Neither are the parameter names taken for granted in most of the class reference.
In this PR the descriptions are mostly okay, in my opinion, considering it's better to keep them consistent with the surrounding TextServer-related documentation (which is arguably more important), as well as to avoid redundancy. Regardless, it will be worth doing a huge pass someday.

Again, it's easy to understand these as a professional, but exposing methods and assigning them very terse and cryptid descriptions is one sure way to make the reader feel uneasy, like they're interacting with something they shouldn't be doing.

[Mickeon]

Are we sure we want to expose what is essentially a reserve method to the public API? I would be very wary since this is a very prickly topic of discussion.
(Note that clayjohn got originally confused by the purpose of the linked PR).

[bruvzg]

With the way TextServer is implemented (to be implementable as GDExtension), I do not think it is possible to have non-exposed methods. And unlike Dictionary, TextServer is a low level API most users won't ever interact with, so it should not be an issue.