Refactor TextEdit into two classes (text and code focused)

[akien-mga]

TextEdit is a generic control exposed to games and the scripting API for text input from the user. It's also the base control used in the various code editors of the engine (GDScript editor, TextFile editor for arbitrary text files, shader editor). Due to that, many features have been added to its API for the sole purpose of editor tools, making the class harder to maintain and with a sizeable share on unexposed, editor-specific APIs.

IMO we should avoid adding too many editor-specific APIs to base controls, and we should instead of editor-specific controls that inherit and extend the generic ones. Those may or may not be exposed to the runtime depending on whether they could be useful for e.g. plugins or in-game tools, but they should be separate and well identified controls.

As such I would suggest to split TextEdit into two controls:

• A slimmed down TextEdit that has a general purpose API, to write/copy/cut/paste text.
• A code-focused CodeEdit, that inherits from TextEdit but adds code-specific features such as indentation management, line numbers, code folding, etc.

Possibly, there could even be a third control which would be editor-only, while the above two would be exposed in the core API:

• An extended EditorCodeEdit, that inherits CodeEdit but adds more features specific to Godot's code editors, such as inline color markers, breakpoint gutters, etc. If we feel it's overkill, we can keep those in CodeEdit though, but it's worth discussing.

If we agree on the need to refactor this, we should spend some time designing the APIs to make sure that they can be easily extended for editor needs without having to hack TextEdit.
A recent example: in #28561 I added a feature to convert clipboard indentation on paste, but I can't have it overwrite Ctrl+V because that's hardcoded in TextEdit. The new API should allow overriding TextEdit's input management in CodeEdit and EditorCodeEdit.

[KoBeWi]

Might be related: #28607

[akien-mga]

Might be related: #28607

Indeed, that's another thing which I find quite confusing in the current implementation, so it would be good to rework that too.

[follower]

EditorCodeEdit

[KoBeWi]

Here's a related comment that could be kept in mind for the refactor: #12164 (comment)