Add a metadata field to kernelspecs.

[craigcitro]

Currently, the only way for a kernel to offer additional information about its
capabilities is to encode information into the kernel name or display name;
this information can be useful to clients, especially for things like
filtering a list of kernels.

This adds support for a new kernelspec dict field, metadata. This allows
kernels to add additional information, which clients can then consume as
needed.

Fixes #273. /cc @rgbkrk

[takluyver]

👍 I think this will also be useful for the machinery I'm proposing in #261.

[craigcitro]

Ah, @takluyver, this does seem like it'd be exactly the information you'd want to return as kernel info in find_kernels() in that PR.

That actually brings up an interesting parallel I hadn't realized at first -- internally at Google, we don't use conda/virtualenv/etc at all, but the "different libraries" I alluded to in #273 are a really close analogue to different virtualenvs or conda environments, where each has a fixed set of libraries installed (possibly with particular build configurations for C++ libraries, that sort of thing). So I suspect we're actually solving roughly the same problem -- meaning I can hopefully bootstrap off some of what you're doing in #261. 😉

[rgbkrk]

Since so far there is agreement on this one, its been open a few days, and this fits in with the way we do metadata elsewhere, I'm going to merge this with the acknowledgement that metadata is going to be the wild west just like in the notebook format.

[rgbkrk]

Like we've done in the notebook format (especially per cell metadata) we've explicitly stated that usage of metadata should be namespaced. That could be worth adding on here too.