Part of #2464.

Historically we've been using Queue::main().exec_async (dispatch_async_f), tracing back to b492564 which was included in #853. This works by putting the closure onto a queue, and then executing it on the main thread at a later point (in spirit similar to doing a thread::spawn and forget).

While this works, it is very brittle, since any code that may run after such a call will read stale data until the event loop has run once more. Instead, we'll use dispatch_sync_f, which will block the calling thread until the main thread has had a chance to run it, meaning that whatever state changes may have happened are visible right after any call.

I've left out the things that affect the fullscreen logic, since that is more gnarly, and would be nice to have as a separate commit to allow easier bisection if something goes wrong. Will follow up with another PR for that.

• Tested on all platforms changed
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users

_{Note: I strongly suspect the reason that dispatch_async_f was originally chosen over dispatch_sync_f was because dispatch_async_f works on the main thread out-of-the-box - though @francesca64 may be able to clarify on that.}