* replace "new State(state_name, arg1, ..., arg8)" with "new State(state_name, {...})".
* use Q for promises.
* use promises everywhere.
* split dummy_api out into sub-packages.
* don't import all of the toolkit into the top-level vumigo_v01 object.
* support states that don't send replies (for SMS apps).
* Remove need for testing hook.
  * tester = new Tester("../../lib/go-app.js");
  * Then tester can create a DummyApi instance and do runScriptInContext(script, {api: api});


Future
------

* crazily advanced plan for resource bindings:

  * Add declarative and introspectable type checking to Vumi sandbox
    resources.

  * Write script to generate a JSON file describing the resource API
    from the declarative bings.

  * Copy JSON file into vumi-jssandbox-toolkit.

  * Dummy API on receiving a request:

    * Looks up request in JSON spec file.
    * Validates request the same way Python resource would.
    * Calls small internal handler.
    * Validates response the same way the Python resource would.
    * Returns response.

    * This also makes testing the resource helper classes easier
      because the dummy API is closer to the real resource.

* Consider moving sandboxer.js into the toolkit.


Vumi Go
-------

* add form_addr_type and to_addr_type to Vumi messages yesterday.
* send message to to_addr_type rather than the clunk delivery class.
* have a Contact addr_type that imples sending to the contact over any valid address and
  selects the appropriate addr_type once a channel is reached.
* rationale for two address types:
  * conceptually there is nothing stopping a message being sent from SMS to Gmail -- current protocols just suck.
  * inside Vumi Go, only one address is really relevant most of the time (i.e. from_addr on inbound, to_addr on outbound)
    and the tag plays the role of the other address most of the time.