Prevent swift account deletion

Hi,

I have discovered that through a series of unfortunate events involving a failed `destroy-environment` run (which I believe was due to a slow Swift API response), and a subsequent "working" (ish) `destroy-environment` run it is possible for Juju to erroneously send a `DELETE` HTTP request to the swift account API, which in older versions of swift (and keystone) will result in the account DB for that user in swift being marked as deleted (and the only fix for this is to either a) wait for a cron'd script to clean it up, or b) get someone to manually delete the sqlite3 db for that account hash).

Although I've been unable to find the condition in the environment (e.g. writing/loading the jenv, doing the Remove*(...) calls etc.), but I'm 99.9% recurring that this is the cause for the issue I've had with my Swift account getting into a hard-to-recover state

I've added a simple check to `provider/openstack/storage.Remove(...)` to ensure the containerName isn't empty (which on a call to delete the container itself, the last step in a destroy env cleanup, will result in a `DELETE` call to the base URL instead, which swift+keystone will gladly oblige in some OpenStack setups).

I couldn't figure out how to test this correctly, due to the way the Storage instance is created/used in the openstack tests, so any pointers on this would be appreciated.

I feel it's more important to catch this nasty edgecase here above finding it's cause in the env handling purely because it is so destructive in the openstack provider compared to others (e.g. you can't remove the base in S3 so easily).
My theory (which I will attempt to later now that I have a working environment again) is that if `destroy-environment` hangs due to a hanging API call, and the process is killed after the bucket is DELETEd (e.g. by the user ^c'ing) then the jenv will be serialised without the container-name, as it no longer exists, but on a subsequent `destroy-environment` this means the DELETE is sent to the swift account URI instead.

I agree that the underlying issue should be fixed, but I think this should be specifically caught here in the OpenStack storage provider due to it's extremely destructive nature in the context of the Swift API.