Kernel and session javascript cleanup

This pull request fixes `kernel.js` and `session.js` to be more respectful of abstraction barriers, and makes it easier to track the kernel state. Some of this is just rearranging functions so they are in a more logical order, more major changes include:

* After the kernel has been started, all interaction should be through it, rather than through the session, with the exception of (1) renaming the notebook and (2) deleting the session
* Remove the `Kernel.running` variable, as its state was not always consistent. Instead, introduce the distinction between "kernel exists" and "kernel connected". For most intents and purposes, to check if the kernel is running you can now call `Kernel.is_connected()`
* Fully support all REST API functions for the kernel and the session.

In terms of event messages regarding the kernel, there are now:

* status_started.Kernel -- the kernel has been started (either through `Kernel` or `Session` but is not necessarily connected yet)
* status_connected.Kernel -- a connection has been established to the kernel
* status_restarting.Kernel -- the kernel is restarting
* status_interrupting.Kernel -- the kernel is being interrupted
* status_disconnected.Kernel -- there is no connection to the kernel (either it has been lost, or there never was one)
* early_disconnect.Kernel -- a connection could not be made to the kernel
* status_dead.Kernel -- the kernel was alive at some point, but has since died
* no_kernel.Kernel -- there is no kernel (either it could never be started, or it died)
* status_idle.Kernel -- the kernel is idle
* status_busy.Kernel -- the kernel is processing a message

There are no more session events (and I don't think there should be -- the Session is pretty much invisible from the user's perspective). I think it might be good to additionally document these messages e.g. in an IPEP or something, that way there's some reference for understanding what events should be used when (and what the format should be for when new events are used).
Not any good reason in particular, to be honest. I started using `@function` because that's what's listed in the jsdocs, and then changed the existing `@method` statements (because there were only a few) to be consistent. I could change everything to `@method` though if that's preferable.