UTF16 broken on Mac still

[MSGhero]

Related to #2300 and company. It seems like Unicode characters on Mac don't work on latest, and the resolution for Windows/Linux/etc doesn't seem to fix it.

Needs more investigation, as I cannot test on Mac to play around with it. I would also be concerned about iOS, since that one was never confirmed either.

(This is the addUTF16 ifdefs within TextLayout)

[barisyild]

I have a same problem.

[MSGhero]

Couple ideas:

• Add a haxedef for HX_SMART_STRINGS
• Add a condition for mac that uses addUTF32 instead of addUTF16 (same parameters)
• Try addCodepoints (same parameters)
• ~~Add mac to the HL condition~~ this one doesn't work
• Put a trace inside addUTF16 to see if the supplied pointer is actually pointing to something (ie nonzero)
• Instead of text.wc_str(), try text_wchar_str()
• ~~get a PC~~

[joshtynjala]

As best I can tell, the final #else with addUTF16() works correctly on macOS, so only Neko and HL will need special cases.

I confirmed that the following example from #2264 was fixed after this small change (in commit f8301ce):

var _body:TextField = new TextField();
addChild(_body);
_body.text = 'фыва йцук';

It no longer renders "DK29F".

macOS Monterey 12.1 Haxe 4.2.4 OpenFL commit f8301ce Lime 7.9.0