Create KernelTypeApp application

[kevin-bates]

We need to create an equivalent to KernelSpecApp. We should call it KernelTypeApp for two reasons:

1. It will be creating Kernel Type definitions for the KernelSpec provider. So while it's creating kernel specifications, they will be cognizant of Kernel Types and any of the features that the new kernel management machinery might produce.
2. We need to be able to coexist with jupyter_client applications on the same installation and KernelSpecApp is jupyter_client's tool. If we shared the name, then the console scripts would collide and last (or first, not sure with python deployments) writer would win.

[takluyver]

Actually, maybe we want both KernelSpecApp and KernelTypeApp.

Kernel types in general can't be created by a set command, because it's up to kernel providers how they are defined. So the only things we can do with kernel types in general are list them, and launch instances from them. Maybe the jupyter-kernel command should grow a --list-kernel-types option to avoid proliferating commands?

The subset of kernel types defined by kernel specs are something we know how to create and delete, in contrast. So the interface for this should still refer to kernelspecs. Sorry, I had forgotten what the commands did.

[kevin-bates]

Yes, every provider should provide a means of creating the discoverable entity. I suppose for some, that may not be applicable. Also, there could be some providers whose consumable entity is completely virtual and will rely on the launch parameters to "configure" the "kernel specification" on the fly.

I see either side. KernelTypeApp or KernelSpecApp for creating the entity. I chose the former simply to retain the ability for juypter_client's jupyter kernelspec to co-exist - which I view as a requirement. FWIW, I have named the two remote provider pps I've created for PoC purposes - jupyter yarn-kernelspec and jupyter k8s-kernelspec. It was before I realized co-existence should happen. I have no issues changing their names, but wanted to mention them.

If we take the approach of using jupyter kernelspec as the command name, how do we co-exist with jupyter_client installations?

Regarding proliferation, I'm all for reducing it. I do see a need to be able to list available entities across providers. Perhaps kernelTypeApp is solely for listing things? jupyter kernel-type list would then produce two columns of information, the Kernel Name and Provider Id. We could also display the resource directory - although not all providers will have one.

KernelSpecApp (or whatever the thing is that creates specs for KernelSpecProvider) would also provide a list option (as should all provider-specific apps) that would then include the directory where the xxxkernel.json file is located - since that's important for troubleshooting.

Thoughts?