container.submit() leaves "orphaned" containers on error

[msherman64]

This issue addresses the user-facing error pattern where:

1. user runs "container.create, container.submit"
2. some error is raised
3. the user tries again
4. the user receives "name is already in use, please use a uuid" error
5. the user must now go to horizon and manually "force delete" the errored container, as container.delete() doesn't work if an ID isn't set.

Detailed Context:

Assuming we have called:

my_container = chi.container.Container(...)
my_container.submit()

The expectation from my_container.submit() is that after running, a zun container is created, my_container.id = the uuid of the zun container. This is necessary for follow-on calls to interact with that contianer, and inspect its state.

However, this assumption fails if an error is raised while waiting for the zun container. Common cases include timeouts waiting for the container to start, failures pulling container images, scheduling errors, invalid "command" arguments, and so on.

This implies that a container "error" state should be a normal, supported state for this interface, to allow users to investigate and fix the issue.

Further, because the ID is not set, the current tool falls back to using the container "name", and raises an error if run twice without cleaning up, which must be done out-of-band due to the missing ID.

Desired outcomes:

1. if running container.submit() creates a zun container, in any state, the ID must be set. This is exactly the case where the zun_container.create API returns a successful http response code. If the zun api returns a failure code, we must raise.
2. running container.submit() a second time, if ID is already set, should be a no-op and return the existing container. (maybe? should it raise?)

Addressed in #94