Support renaming a database

@davisp:
>Distributed systems makes renaming things hard since the dbs db is eventually consistent. For a stop gap, a tool to do the rename offline (ie, stop all nodes in the cluster) could probably be done easily enough.

@janl:
> good call, I thought that was going to a be a thing. First reaction was maybe `_dbs` docs allow for an `alias` that all nodes can converge towards, dunno if that actually works tho

@davisp:
>Also, some of the obvious changes we could make here to do this in an eventually consistent fashion:
>
>1. Replace the dbname -> shard file name mapping, ie, when we create a database document it stores a UUID that we reference on disk.
>2. Similar to UUID but the "rename" or "alias" doc just lists the original filenames on disk
>
>The downsides to these approaches is that there's currently a large amount of operator knowledge based on the fact that database names map to file system locations. If we break that mapping then we'll have to work on tooling for anyone operating a CouchDB cluster.
>
>Also, with alias docs we'd end up having a single database available under two different names without some other sort of voodoo. So that might be something to think about (though it seems fine on the face of it, just maybe surprising to customers in corner cases).

@wohali:
>There actually was a request for DB name aliases 5 years ago in the 2012 summit - so that is very on topic @davisp.

Also, this would help with things like adjusting a db's q (replicate to a new db then change the alias when it's ready). It occurs to me that this would help with compaction, too?

No file, test, or entry point is identified. Begin by reviewing CouchDB’s database naming, _dbs consistency, shard-file mapping, alias behavior, and offline cluster operations; done requires an agreed design and implementation scope, which this discussion does not yet provide.

Written by the indexing model from the issue text.