Websocket RPC infrastructure

This adds Websocket-based RPC infrastructure to Generator. Much of this code originally came from [Brackets-shell](https://github.com/adobe/brackets-shell/tree/master/appshell/node-core), but has been refactored and simplified for this use case. 

This pull request adds the following methods to the `Generator` object:

* `Generator.prototype.getCustomOptions` - Asynchronously stores a dictionary per-plugin in the Photoshop memory space. Accessible via ExtendScript.
* `Generator.prototype.setCustomOptions`- Asynchronously retrieves the aforementioned dictionaries per-plugin. 
* `Generator.prototype.startWebsocketServer` - Starts the Websocket server per-plugin. The port can either be specified or dyamically assigned.
* `Generator.prototype.stopWebsocketServer` - Stops the Websocket server per-plugin. 

To test:
1. Install the [generator-rpc-example plugin](https://github.com/iwehrman/generator-rpc-example)
2. Clone the [node-connection-example](https://github.com/iwehrman/node-connection-example)
3. Run `bower install` in the `node-connection-example` directory
4. Visit `file://.../node-connection-example/index.html` in Chrome

The `node-connection-example` relies on a hard-coded port number that's shared between the example plugin and the example client code. Eventually the [generator-connection](http://github.com/adobe-photoshop/generator-connection) repo will be updated so that Photoshop can (by some mechanism) be used as the intermediary to communicate dynamically assigned ports, but it doesn't do that just yet.
I believe the code in this function that does the Promise wrangling will work. However, I'm not totally sure why the complexity is necessary.

For a given pluginId, why can't we just do the following:

1. If `pluginConfig.websocketServerPromise` is defined, just return the promise (regardless of the state of the promise).
2. If it isn't defined, we need to make a new server. Immediately make a new promise, and assign it to `websocketServerPromise`. Kick off the server creation process, and return the (not yet resolved) promise.
3. If server creation fails, reject the promise, and then `delete pluginConfig.websocketServerPromise`. That way, everyone will be notified, and we'll create a new server on the next call to `startWebsocketServer`
4. If server creation succeeds, resolve the promise with the port number (and leave `pluginConfig.websocketServerPromise` set, while synchronously setting `pluginConfig.websocketServer`). Future calls to `startWebsocketServer` will return this promise.
5. When stopping a websocketServer, check if we have `pluginConfig.websocketServerPromise` set. If it's set and resolved, just delete it. If it's set but not resolved, reject it and delete it. Also delete `pluginConfig.websocketServer` and start the shutdown sequence. Continue to use a completely separate promise for notifying when shutdown is complete.