Swizzle sendEvent: instead of subclassing NSApplication

[madsmtm]

This is done to avoid order-dependent behavior that you'd otherwise encounter where EventLoop::new had to be called at the beginning of fn main to ensure that Winit's application was the one being registered as the main application by calling sharedApplication.

Fixes #3772.

This should also make it (more) possible to use multiple versions of Winit in the same application (though that's still untested and officially unsupported).

Finally, it should allow the user to override NSApplication themselves if they need to do that for some reason.

The solution chosen here, method swizzling, is a bit magical (though fully supported by the runtime), alternatives include:

• Attempting to override if NSApplication, and exposing a method for users to call themselves if they override NSApplication. This would be quite confusing, since suddenly overriding the application class would disable parts of Winit's behaviour (unless you knew to call this exposed method), and it still wouldn't fix the ordering issue.
• Creating a subclass of the user's NSApplication, and class-swizzling that in. This is still swizzling, and would just be more work to do (note also that we wouldn't be able to add instance variables to such a class, since we don't allocate it ourselves).

Just to re-confirm that overriding sendEvent: is a good idea by itself, I'll note that this is also what's done in other UI frameworks, including the SDL and FLTK.

• Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
  • It is rare enough to want to override NSApplication that I doubt it makes sense to provide an example. We already have an example of overriding the NSApplicationDelegate, that should be enough.
• Created or updated an example program if it would help users understand this functionality