Chore: move editor text elements into separate files when possible

[CatHood0]

Description

The decision was made to separate the text element widgets into their own separate files in order to not only separate the logic, but to make it more readable and easy to debug.

This decision was made since there are many files with this pattern, of having a lot of internal logic that is not completely related in the same place, being that we could separate them into different files.

If this PR is merged, we will likely continue to do this type of refactoring since it improves readability and makes it easier to implement solutions since we do not have to read a 1600 line file.

arabianRomanNumbers and romanNumbers from text_block file because they were no longer used internally and were just taking up unnecessary space.

[!NOTE] I did not separate the members within text_selection because @echoEllet is currently making changes within this file, so it would be better to wait for them to complete and then split them.

• [ ] ✨ New feature: Adds new functionality without breaking existing features.
• [ ] 🛠️ Bug fix: Resolves an issue without altering current behavior.
• [x] 🧹 Code refactor: Code restructuring that does not affect behavior.
• [ ] ❌ Breaking change: Alters existing functionality and requires updates.
• [ ] 🧪 Tests: Adds new tests or modifies existing tests.
• [ ] 📝 Documentation: Updates or additions to documentation.
• [x] 🗑️ Chore: Routine tasks, or maintenance.
• [ ] ✅ Build configuration change: Changes to build or deploy processes.

TODO:

• [ ] we need to test if these changes don't break nothing.
• [ ] we need to add some documentation easy to understand for the new files.

[EchoEllet]

Will review it soon. It's usually more effective to review those changes in the IDE or command line instead of GitHub Web.

[EchoEllet]

Still need a bit more time before working on #2251 or fully reviewing this change. We need some tests to ensure that we're not exposing any file that have @internal in it to ensure that user can't accidentally use an internal API. I do get reports about breaking changes when it's not clear that this is an internal API or accidentally made out to the public by a PR.

Added a breaking changes section to explain this in #2275 though still not quite enough. Should require minimal effort to fix. The issue that we're not using @internal when we can and that's something to address.

[CatHood0]

I apologize for the inactivity I have had. In one or two days I will start again, resume activity and continue with the PRs that I have active.

Anyway I have to take some time to remember what I was doing in this PR.

[EchoEllet]

@CatHood0 Do you want me to handle those conflicts? If yes, then I need to push changes to your fork or create a new PR since I'm unable to push directly or merge with master after the updates (insufficient permission).

[CatHood0]

@EchoEllet there's no problem for you to make a new PR if necessary. Thank you very much for taking the time.

[EchoEllet]

Can you push your branch to this repo instead so we can both make changes?

Since I only plan to make minor changes, including fixing conflicts.

[CatHood0]

Can you push your branch to this repo instead so we can both make changes?

It's ready now.

[CatHood0]

This will require more work.

I'm still trying to figure out why some classes are used and exist and why certain things exist (this took me too long). I definitely need to document everything, it's really tiring to see so many RenderObjectElement or RenderBox or RenderContentProxyBox without clear and concise documentation.

It was even confusing to know why RenderParagraphProxy existed, and how RichTextProxy managed to use it so that RenderEditableTextLine and _TextLineElement were used as the "body" using setBody in RenderEditableTextLine to have the methods that RenderContentProxyBox contains (i mention it in the past tense because i already understood how it is done, but it took me too long to understand the connection between all these classes)..

[EchoEllet]

I definitely need to document everything, it's really tiring to see so many RenderObjectElement or RenderBox or RenderContentProxyBox without clear and concise documentation.

This is a bit out of scope for this PR, or maybe too much? I think it's enough to only separate classes into files.