Migrate all event handling logic for events emitted by client-defined modules to Application Core

[seanttaylor]

Client-defined modules should not respond to events emitted from other client-defined modules. The Application Core should respond to an event emitted by one client-defined module by calling an exposed API of the another appropriate client-defined module. This should:

1. Simply the event graph -- events are generally emitted only in a singled direction (i.e. towards the Application Core)
2. Help us avoid event cycles -- in the current implementation all client-defined modules are subscribers and emitters of module events. This can make debugging more difficult and introduce subtle behaviors like event cycles that can be challenge to trace. The existing implementation can also create memory leaks as result of these cycles.
3. Simply unit tests -- the current unit test suite relies to heavily on developers understanding the implementation details of Jest, rather than simple assertions. This is because we trying to mock the firing of events. Once all module methods that respond to events are exposed on the sandbox, we won't need to mock firing an event in order to test whether a method was called: we can just call the method and make assertions on the result.

Notes:

• Client-defined modules should expose all public methods on the sandbox. Particularly any methods that were previously invoked by an event notification.
• Client-defined modules only emit events that the Application Core is subscribed to.
• If a client-defined module method should be invoked in response to an event, it is the Application Core that listens for the event and invokes the method in the appropriate client-defined module as a response.
• The only events that client-defined modules may subscribe to are those emitted by the Application Core. Events of this kind may be events that are interest to multiple client-defined modules.