Deprecate non HX_SMART_STRINGS paths

[Aidan63]

Having to keep two code paths for text encoding stuff has been annoying me recently, I have two questions.

1. What is the NO_HX_SMART_STRINGS really for? I'm assuming this was just to switch back to the old code in case there were bugs in the new dual encoding system.
2. Is anyone actually using the non smart strings mode, if so, why? I'm assuming if anyone is they ran into a bug, disabled unicode string, and haven't touched it since.

It would be nice if for Haxe 5 we could stop supporting the fallback mode, any new api wouldn't need to support both that way.

[tobil4sk]

We could also repurpose these code paths to have a utf-8 only build which is desirable for some cases.

If it does just get removed, it should happen at the same time as dropping haxe 3 support. I think that should happen later because for now there isn't a stable hxcpp version people could be directed to instead. (I still think it would be good to have a separate haxe5 branch for breaking changes, so that backwards compatible bug fixes could still be released/used without having to be detangled).

[Aidan63]

While a pure utf8 path could be useful I think we'd still have the HX_SMART_STRING conditionals sprinkled around which is what I really want to avoid. I agree that we wouldn't want to remove these code paths until we've got one last 4.x release out and are moving towards a 5.x release.