Cocoa isn't an event-polling API as UE4 expects, so previously we were subverting the NSApplication's event handling to pretend that it was. When the engine wasn't running the event loop fast enough, such as when loading where it isn't processed at all, this resulted in unresponsive windows and Spinning-Beachball-Of-Death. That isn't very satisfactory & to some users appears as if the application has crashed. To address these deficiencies without further attempts to subvert Cocoa, the game is now punted onto a separate thread where it can run its own tight-loop, leaving the main thread to handle the Cocoa event run-loop. Events are captured by delegate objects, as Cocoa requires, but dispatched and handled on the game thread which makes Cocoa appear more like other platform APIs to the higher-level UE4 code.
This can all be disabled using the MAC_SEPARATE_GAME_THREAD define in CocoaThread.cpp.
#codereview michael.trepka
[CL 2262543 by Mark Satterthwaite in Main branch]
#summary Replaced instances of DragDrop::IsTypeMatch with FDragDropEvent::GetOperationAs()
#note Please change any instances of DragDrop::IsTypeMatch for the templated FDragDropEvent::GetOperationAs<>() or FDragDropOperation::IsOfType<>() where necessary
#proj Editor
#branch UE4
#reviewedby Nick.Atamas
[CL 2042222 by Andrew Rodham in Main branch]
