Kernelspecs in REST API for kernels and sessions

This adds support in the REST API for kernels and sessions to launch different kernels by specifying a kernel name. SessionManager is somewhat refactored, so that it, rather than the session HTTP handlers, control the connection between sessions, notebooks and kernels. The JS APIs are also updated to deal with the new parameters, but for now the notebook JS always starts the default kernel.

I have one question, about the connection between sessions and kernels. Killing a session's kernel through the kernel API (rather than by deleting the session) leaves a hanging session in the SessionManager. This was already the case, but now the SessionManager tries to look up its kernel, which fails with an error. This is a state that should never be reached (kernels started by creating a session should only be killed by deleting that session), but I think the API should behave more gracefully if it is. Currently, a request to list sessions while in that state fails. Should it:

1. Delete the session. This seems an obvious course, but might cause problems for the frontend if it's left with a reference to a Session object that no longer exists on the backend.
2. Return the session model with `kernel: null` in the JSON. I'm leaning towards this - it makes it clear what has happened.
3. Restart that kernel. This seems bad, and it's not even clear that it's possible: the name of the kernelspec to launch is stored on the KernelManager object which has already gone.
Can you put default_kernel_name in a class-level variable? That will make it easy to override in custom.js while we wait for the UI to pick kernels.