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.
When CURLOPT_READDATA is specified, not only must we set CURLOPT_READFUNCTION, but we must also set CURLOPT_SEEKFUNCTION to ensure that the data can be resent if there's a redirect.
The new version no longer checks the return code of `SDL_GetWindowOpacity`, for consistency with the other getters. In theory this should be fine, because the only documented error condition is if the window is invalid, at which point none of the getters matter. If the platform doesn't support transparency, "opacity will be reported as 1.0f without error."
