Support Events as actions

## Motivation

So it looks like the plug-in approach #26 will use notifications to communicate with the core. This
opens new possibilities for integrations. For example, issue #49 is about web socket support. Such
a feature can live in a plug-in w/o problems.

However, web sockets are async in nature, that is, they can receive messages at any time. How
would users be able to react on those events?

**Note:** I use WebSocket as an *example* here. This is obviously useful for catching other
events and could replace the hard-coded "system events" in Jasonette.

## Proposal

I propose a new action type for events. Those actions would "register" itself for a notification
handler by name:

```
{
...
{
// register hypothetical web socket
"type": "@JasonetteWebSocketPlugin.connect",
"options": {
"url": "wss://example.com/ws/echo"
}
}
...
// register for events
{
"type": "!WebSocket.message",
"success": {
// do whatever you want here. Will be called on the 'WebSocket.message'
// notification sent by the WebSocket plugin if messages arrive
}
},
...
}
```

## Details

For the above to work, the hypothetical WebSocket plugin would send a notification on received messages with name `WebSocket.message`.

The `!WebSocket.message` action would instruct the core to register a notification handler for
the `WebSocket.message` notification and do a `[[Jason client] success:notification.object]` if
the notification is received. This can be nicely done in a block.

All this could be done in a plug-in also. But this ia s feature which is core-worthy IMHO 😄

## Problems

- The notification handlers would need to be removed when we leave our main view. This would need a registry of some sort.

Review issues #26 and #49 alongside this proposal to understand the plug-in and WebSocket context. Then locate the core action-dispatch and notification-handling entry points; the issue names no files or tests. Done should include event actions that register handlers, invoke the success block with the notification object, and define how handlers are removed when leaving the main view.

Written by the indexing model from the issue text.