Update name handing

[TomAugspurger]

Several things in this library and Kubernetes require unique names. Right now or name handling is a bit of a mishmash, with some things using name and some things using generate_name and letting kubernetes assign a name for us.

Ideally we offer the ability to specify a name and have Kubernetes make sure it's unique with generate name, or provide exact name (raising an error if it causes a uniqueness conflict).

[minrk]

I ran into some issues related to this working on #86.

Part of the challenge is that the Job references the Secret and ConfigMap by name (for env and volumes), and the Secret and ConfigMap reference the Job by name and uid for owner references.

As a result, patching in the secret and config map are done in stages:

1. patch Secret/ConfigMap into the Job spec with placeholder names
2. create Secret/ConfigMap to learn name from generate_name
3. patch in 'real' names to Job spec
4. submit Job
5. patch existing Secret and ConfigMap with ownership references

I think this could be substantially simplified if we knew names ahead of time:

1. generate the unique name locally (or let users pick the final name)
2. use the same name (or as a prefix) for Job/Secret/ConfigMap
3. create Job first
4. create Secret/ConfigMap with ownership references from the start, instead of patching

This is basically what we do now in KubeSpawner.

Letting users pick names and handle uniqueness is essentially handled already by the fact that the 409 Conflict on job creation will now propagate to the user. This will behave better if the Job is created first, so the Secret and ConfigMap are never created if the Job conflicts.

I think the benefits of relying on kubernetes' internal generate_name are limited by the fact that kbatch controls the namespace, so race conditions on names are extremely unlikely in practice. Our own random suffix (especially with a monotonic sequence as a component)