Replace tt_string with wxString and other alternatives

[KeyWorksRW]

Description:

Prior to wxWidgets 3.3, the wxString class was not a good choice for a general purpose string container -- std::string was still preferred for lower memory use and higher performance. However, with 3.3 and the wxUSE_UNICODE_UTF8/wxUSE_UTF8_LOCALE_ONLY settings, wxString uses std::string as it's underlying storage, making it viable as a standard string container.

The tt_string classes were developped to provide additional methods operating on a std::string, many of which were similar to what wxString provided but without forcing UTF16 strings when used on a Windows system. Between wxString 3.3 and a possible tt_wxString class derived from wxString, the tt_string class is no longer needed.

AI coding assistance (e.g., github copilot) will typically understand how to use wxString given a large number of repositories that use it, but will have very limited knowledge of the tt_ classes. In addition, for an open source project, it can be helpful to provide as many standard functions and methods as possible so that devs (or AI) can utilize them in their own code. That's not going to happen with any code using tt_ classes, since the entire library of classes would need to be included.

Note that the tt_ classes were based on even older classes that pre-dated std::string. As such, much of the classes and methods do not utilize modern coding practices, particularly given that wxUiEditor requires C++20. Rather then modernizing the tt_ classes, it would make sense to look at complete replacements: wxString, tt:: functions that use wxString, and a new tt_wxString class derived from wxString.

It's not practical to remove all of the tt_ functionality since we rely heavily on some of the functionality. However, we could reduce the dependence on the tt_ classes:

1. Use wxString instead of tt_string in cases where the methods used in tt_string have equivalents in wxString.
2. Replace the tt:: namespace functions with ones that take wxString as a parameter and/or return wxString as a result.
3. Create a tt_wxString class for those cases where 1 & 2 above are insufficient, such as needing to return a std::string_view. Note that wxString::m_impl is private: so we can only get a non-modifiable reference to the std::string that m_impl is typedef'd as.

The goal would be to use wxString as much as possible. If needed, tt:: namespace functions could be used for additional functionality. Using a tt_wxString class would be a last resort for those cases when the other methods aren't practical. However, there will still be other tt_ classes until wxWidgets moves to C++17 and fully supports std::string_view. Until then, there's still a place for tt_wxString in code that already has to use a tt_ class.

[Randalphwa]

The next PR will make a major step towards this, adding a new ttwx:: namespace and two vector classes. It will also begin the work of modernizing and cleaning up the code to improve readability and reduce lint warnings (clang-tidy in this case). However, this is a large undertaking to update the entire codebase, so this will be an ongoing change while other functionality is updated/added.

[Randalphwa]

I'm not sure a tt_wxString class is really needed -- I'd like to avoid that if at all possible to make the code more available for open source and of course AI training without requiring any more custom classes then are absolutely necessary.