update API: include all SRP/stretching parameters, change salt names

If we update the code to implement these APIs, we'll be able to deliver
all the stretching/salting information the client needs. The current API
spec is too limited in some places (only delivering one number for
stretching, when actually we need 5 plus a type, and overspecified in
others (naming a hash algorithm and group-size-in-bits for SRP, when
really it should just be a single name for the whole parameter set).

I'd recommend calling the SRP salt "srpSalt" rather than "s". There is a
different SRP object named (capital) "S", which absolutely must be kept
secret (it is the derived shared key), and using the same letter for
both is bound to confuse somebody down the line into publishing "S" by
mistake, which would be disastrous.

Feel free to fix the spelling (e.g. scryptN instead of scrypt_N), I
don't know what the local conventions are.
Rewrite API docs to match 31-Jul-2013 design.
docs/api.md: update internal anchor links
api.md: /password/change also returns a keyFetchToken

We want this to grab kB before submitting an account reset.
api.md: rename /password/change to /password/change/start
Minor api.md changes

* fixed json typos
* changed /account/delete to /account/destroy
* fixed error example
updated /account/create to next api
updated /account/reset to next api
implemented new /auth/start /session/create
changed recovery_method to recovery_email
implemented /password/change/start stubbed /password/*
fixed mysql test timeouts suboptimally. fixes #116
docs: email should be hex-encoded UTF-8, to avoid ambiguity

If we sent it as raw unicode, then it would get encoded by the HTTP
agent, decoded by the server's HTTP stack, then delivered through who
knows what to the IDP application code. Each step is an opportunity for
something to go wrong and mangle the string, which would break the
key-derivation being done by both sides. It's safest to encode it
exactly once, at the beginning, according to our API spec, and send only
boring ASCII over the wire.

Conflicts:
	docs/api.md
clarify docs: single-use tokens are consumed by failure too
docs: mark the two calls that fail unless the account email is verified
encode email as a hex string of UTF-8 bytes
added some string length bounds on request parameters
improved the 'npm start' logging experience
updated AuthToken behavior for multiple contexts
added /account/destroy integration test