Explicitly separate an api package

[SpencerPark]

A fairly large part of the base kernel here is to facilitate a common interface for kernels on the jvm such that things like mime rendering and magics can happen without depending on a certain kernel. There are already some common magics and rendering registrations to support this.

The project here should better restrict itself to be an implementation. To avoid such heavy dependencies on third party integrations, we should split out an interface (api package) that this project implements. Such an api would be very small and primarily contain the interfaces as well as a good majority of the documentation that I've been slacking on here. Some exceptions are the Comm abstract class and things like RenderContext.

The motivation for moving a class to this new package should be: "Could a third party library that is not writing a kernel need to use this?"

[SpencerPark]

Work is now taking place on the restructure branch. In addition to pulling an api out some of the other packages like the client and probably widgets, will be moved in here.

As part of working on the api separation, there is another that should take place. The plain protocol classes should move to their own package (with dependents basekernel and client). The default extension implementations like Renderer and Magics should also be on their own as they could be useful outside of the context of a kernel.

So in total (at this point) there should be: api, basekernel, client, protocol, extras-defaults, and widgets.