Post-V2: Rewrite `TextFormatter`

[tig]

We've discussed all of the cruft in the current TextFormatter design and implementation many times.

This Issue is to collect all of the issues and track a re-design an re-implementation.

This Issue is marked as POST-v2 as the current implementation actually works fine for the most part and we have much bigger fish to fry. but post V2 we should tackle this.

Problems with Current TextFormatter

• Format and Draw are decoupled - Draw does a significant amount of "formatting". The impact of this is getting the size of the formatted text (e.g. FormatAndGetSize() is error prone. This is critical for Dim.Auto(Text)... and means the current implementation of that has a bunch of hacks.

• TextFormatter.AutoSize is completely useless (and no longer used by the core View class). This is because it couples width and height (and because of the aformentioned Draw/Format decoupling).

• Performance - The current implementation is horribly inefficient and the design is such that Format gets called many-many times during operations like LayoutSubviews/SetRelativeLayout.

• We now have a simple, robust, alignment engine: Aligner. The current implementation has a very complex, spaghetti-code, alignment/justification implementation - It is now well tested, but the unit tests for it are actually unit tests of higher-level functions, like View.Draw.

• Poor extensibility and no replicability - As @tznind noted in #3586, adding gradient formatting will be a ton of work given the nature of the current code. This is an example of poor extensibility. For replicability, a possible path for addressing #1642 would be to have multiple TextFormatter implementations. E.g. one for "Attributed Text" and one for "HTML".

• TextFormatter.WordWrap is fragile and confusing.

• (Please feel to add more!)

Great things about the current TextFormatter

• It is actually a magnificent example of a poor-design applied to a very complex problem where ingenuity and hard-core-brute-force-work has led to something that actually, shockingly, works very well for most use-cases. The TextFormatterDemo Scenario illustrates just how powerful the current engine is.
  • Horizontal & vertical text alignment, including Fill/Justification.
  • Horizontal & vertical text direction.
  • WordWrap.
  • Wide char support.
• Code coverage with unit tests is actually pretty good. Most of the testing is via higher-level constructs (e.g. View, Label, etc...), but it's not bad.

Issues & PRs with valid context

• https://github.com/gui-cs/Terminal.Gui/issues/3418
• https://github.com/gui-cs/Terminal.Gui/issues/3275
• https://github.com/gui-cs/Terminal.Gui/issues/3229
• https://github.com/gui-cs/Terminal.Gui/issues/3469
• https://github.com/gui-cs/Terminal.Gui/pull/3586

[dodexahedron]

To be fair to all who have battled that beast, Unicode isn't easy.