Devoncarew window events

Fixes #115.

This introduces a mechanism to allow us to override generated code with hand-written methods, and uses that to add some events to AppWindow, and override the generated ones on ChromeAppWindow.

The idl defines the window events on the ChromeAppWindow class. The implementation has those events on the AppWindow class. I don't believe the issue lies in the code generator. In many (most? all other?) cases, you can listen to events on the `chrome.foo` object. This is the outlier. So I expose the events manually in the window class and proxy through to them from the `chrome.app.window` API class.

The override mechanism allows a user to place a patch file next to a generated file (`foo_patch.dart` next to a generated `foo.dart`). Based solely on the file name convention, the file will be part'd into the generated file. This allows generated code and hand-written code to be orthogonal to each other but both files be valid dart code. Another mechanism in the overrides.json file lets developers rename classes in a very specific way. You can mark `A` as 'overridden'. This means that it will be generated as `_A` but everyone will continue to try and instantiate `A`. The part then needs to declare a subclass of `_A`, named `A`. In this way it can selectively override methods.