Previously, we added these rpaths to lime.ndll when it was built in commits c70ec9f and 333d093, but it's actually necessary only for Neko, so now I made it happen specfically after calling `nekotools boot` to create the Neko executable.
I've tested cpp and hl, and I've confirmed that the executables still launch successfully when these rpaths are omitted. It's better for their security to use fewer rpaths.
As noted commit c70ec9f, adding these rpaths is necessary due to a change in Xcode 15 where /usr/local/lib used to be available on the rpath automatically, but now it isn't, which affects the executable's ability to find the libneko dylib.
This is where arm64 homebrew installs `libneko.dylib`. However, it may still be in `/usr/local/lib` if installed via the haxe .pkg installer, so we add both.
On ios, we build statically linked executables. This means that if lime uses mbedtls 3, hxcpp is also forced to use it which can cause crashes and other problems, as hxcpp is currently written for 2.28
I'd forgotten that they have their own list of dependencies. And sure, we could copy their list, but I worry that we'd forget to update it. This way is easier and takes less space.
The app's Timers should still continue when a window is hidden. Especially since an app could have multiple windows, with some being shown and some being hidden. If only one were hidden, the other shown windows would clearly behave in a broken manner because the one hidden window would cause all app timers, even those associated with other windows, to be paused.
Introduces new WINDOW_SHOW AND WINDOW_HIDE events from C++ to Haxe, and new onShow and onHide events on Haxe Window.
Followup to 0918ee2381
On SDL_APP_WILLENTERBACKGROUND and SDL_APP_DIDENTERFOREGROUND, inBackground was being toggled, but it was not toggled on SDL_WINDOWEVENT_SHOWN and SDL_WINDOWEVENT_HIDDEN. However, both pairs were dispatching WINDOW_DEACTIVATE and WINDOW_ACTIVATE from C++ to Haxe. When inBackground wasn't toggled, the UPDATE ApplicationEvent continued being dispatched from the C++, but the Haxe assumed that it wouldn't be. This meant that timers were still updated after WINDOW_DEACTIVATE for SDL_WINDOWEVENT_HIDDEN, but then they were still "advanced" as if paused on WINDOW_ACTIVATE for SDL_WINDOWEVENT_SHOWN. The next update time would be some time in the future, roughly equal to how long the Haxe thought the timers were paused. This could make it seem like the timers completed stopped updating, especially if they should have been paused for a long time. They would eventually continue, but they should have paused on WINDOW_DEACTIVATE and continued immediately on WINDOW_ACTIVATE.
