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.
I love/hate optional properties :)

If they are simple and have an obvious default value, that makes sense... Say `maxRetries` on the queue, we can set that to a 5 by default, that relatively sane...
But we don't provide a default value for `created` and `deadline` on the queue, because that makes the request non-idempotent.

There are exceptions to the following rules, but generally:
A property is **optional** if it is simple and a default value makes sense. In this case the default value is provided inline in the JSON schema. Good example is `task.retries` if not are specified the [default value is 5](https://github.com/taskcluster/taskcluster-queue/blob/master/schemas/create-task-request.yml#L75)
Default values specified using `default: <value>` in the JSON schema will be substituted in by our JSON schema validation routine. And they will show up in the documentation ! :)
This works best for value types, lists and objects are not good idea (I'm not sure our JSON schema validator will deep clone these, or clone them at all).

A bad property to make optional is one that is not a simple value type... We do have exceptions, but we mainly make these exceptions to make the API easier to use. IMO, there is no reason to make this API easy to use, I would rather that it is fairly explicit. After all this component provisions hardware, when you make a change here you better have considered all the options, making them non-optional forces you to do so :)