Remove W-suffixed Python methods and always support Unicode properly

[dgelessus]

Working on removing the remaining non-Unicode-aware Python methods, which I previously bumped into in #1297. The following classes still have separate W and non-W methods:

• [x] ptGUIControlEditBox, ptGUIControlMultiLineEdit, ptGUIControlTextBox - all three classes have getString/setString methods, so doing them at once allows me to safely use a mass search/replace
• [x] ptGUIControlListBox
• [x] ptGUIPopUpMenu
• [x] ptPlayer
• [x] ptVaultFolderNode (and its subclasses ptVaultAgeInfoListNode and ptVaultPlayerInfoListNode)
• [x] ptVaultImageNode, ptVaultTextNoteNode - both classes have getTitle/setTitle methods, so I'll do these at once too

I've only done "surface-level" testing for most of the changed script code. However, most calls touched by this change fall into one of the following categories that shouldn't need much testing:

• They already used a W-suffixed name, so the behavior remains unchanged.
• The called methods already had full Unicode support without the W suffix, e. g. ptGUIControlTextBox or ptPlayer methods, so the behavior remains unchanged.
• They are only used in combination with ASCII string literals, so the behavior is the same regardless of whether the Unicode-aware code is used.

As far as I can tell, only the following calls are actually interesting:

• Scripts/Python/ki/__init__.py:1630 - xKI.MessageHistory - Typing non-ASCII text into chat and then pressing up-arrow caused a UnicodeDecodeError. Fixed by this change.
• Scripts/Python/ki/__init__.py:4773 - xKI.BigKICheckSavePlayer - Typing a non-ASCII player name into the "add buddy by ID or name of in Age" dialog and pressing Enter caused a UnicodeDecodeError. Fixed by this change.
• Scripts/Python/ki/__init__.py:6441 - xKI.ProcessNotifyMarkerFolderPopupMenu - This seems to be unused code related to timed marker games. Even if it was used, the referenced localization strings are pure ASCII and so shouldn't cause any problems.

Feedback welcome on whether I should squash the commits further in the end. Keeping them separate makes it possible to see which calls were still using the non-W-prefixed methods (and were thus potentially not Unicode-aware). Squashing them together would eliminate some back-and-forth changes (making git blame a bit cleaner).

[Hoikas]

Feedback welcome on whether I should squash the commits further in the end. Keeping them separate makes it possible to see which calls were still using the non-W-prefixed methods (and were thus potentially not Unicode-aware). Squashing them together would eliminate some back-and-forth changes (making git blame a bit cleaner).

For now, I would say keep the transitional commits. I wouldn't worry about squashing anything until the work is complete, and, even then, it might be better to just keep the commits as they are. As long as your history tells a story that makes sense, I'm not picky either way.

[dgelessus]

Alright, that's all the easy obvious stuff taken care of. That is, all Python methods that had both W and non-W versions now have just one suffix-less version that is fully Unicode-aware. I've also deleted the old, non-Unicode-aware code from the C++ side of pfPython.

There's still more work to be done here, which I think would be better off in a separate PR, because it's mostly separate and might be less straightforward. Specifically:

• A few Python methods still support only narrow strings, i. e. they don't even have a W-suffixed version. This includes e. g. ptBook and ptVaultChronicleNode. I haven't touched these in this PR.
• Some code in e. g. pfGameGUIMgr still has separate methods/overloads for narrow and wide strings - these could probably be removed once the previous point is taken care of.
  • That code seems to be one of the main users of hsStringToWString and hsWStringToString - perhaps those can go soon afterwards...
• A lot of this code hasn't been ported to ST::string yet.

[dgelessus]

As mentioned above, I've only done thorough tests for the few code paths that looked (previously) problematic to me. Everything else looked trivial to me while reading through the diffs. Let me know if you notice anything that I should re-test in particular.