Jhford rewrite

I have the basic API written.  I'm not sure how to get generate an api reference json blob, so i don't have it in the client, which results in Auth being next to impossible to do.  For now, I have the deferred authentication commented out.

All of the messages (other than ping) have JSON Schema set up, and I don't suspect that they will change.  I need to add a stats method as well.

I have a couple of questions in routes/v1.js regarding scopes, and I'm not sure what you mean about the scope escalation thing.

For the Worker Type entity, I'm storing things in entity keys, using JSON to represent them, which is working well for all cases other than when a value is undefined.  It would be nice if we could store an entity value as undefined.
1) Yes, we should have separate scopes...
The general patterns I've used is:
  * `<service>:<action>:<resource>` (relevant in this instance)
  * `assume:<role-type>:<role>`  (not relevant here)

In this case `<service>` would be `aws-provisioner`, `<resource>` is the workerType and actions would give rise to scopes:
 * `aws-provisioner:get-worker-type:<workerType>`
 * `aws-provisioner:create-worker-type:<workerType>`
 * `aws-provisioner:modify-worker-type:<workerType>`
 * `aws-provisioner:remove-worker-type:<workerType>` (I try to avoid `delete` because it's a js keyword)

When you have multiple dynamic entries like workerType (that isn't logically nested), one of them often turns out to be a role... Or we'll model it some other way.
Note that generally, it's not critical to get scopes right the first time, as we rather easily modify them and change all clients that have them. Especially in this case, we won't have many tightly scoped credentials :)
In this case a single scope for everything would probably work fine, but being able to scope it is nice, and very easy to do :)

For listing I have mixed feelings. Perhaps we can make it a public API end-point and only return the list of valid workerTypes?
I think such a end-point would be useful in UIs meant to create tasks (where people don't have rights to view/edit workerTypes, but only use them with the queue). In the admin UI modifying workerTypes, you get the list of workerTypes and then when you select one for editing, we can load all the data from that specific workerType.