Refactored data/<data_id>.<timestamp> to...

data/<data_id>/data/<reverse_timestamp>

The reverse_timestamp is (END_EPOCH - timestamp) so that it sorts in
reverse with listings, making things easier and quicker when retrieving
and pruning data.

Also dropped DecryptionError and UnsupportedVersion and just use
ClientException in their places.
data <-> name is now many <-> one

The link between data and name is now "many to one". The
data/<data_id>/name remains the same, containing the "name" entry.
However, name/<name_id> was replaced by name/<name_id>/_ and no longer
contains a "data_id" entry, just the "name" entry. The data ids are now
individual zero-byte Swift objects at name/<name_id>/<data_id> offering
the many links.

Had to change store.get_name_info to reflect that multiple data ids can
match now. store.get_names_info changed a bit too, though it just could
yield the same name and name id multiple times with a different data id
each time.

Now items that used to be like /data/<data_id>/data are now like
/data/<data_id>/_ so that they sort before everything else. This helps
in generators like store.get_names_info to resolve some values before
yielding additional values from further in a listing.

Also made store.put_data always create a new BrimLock object unless the
data_id is explictly given, instead of doing a lookup by name and an
overwrite if matching. This means multiple BrimLock objects can have the
same name instead of overwriting one another. Kind of important in case
you upload fifty "Untitled" objects that you wanted distinct to rename
later.

This does mean the cli.put will always create new BrimLock objects since
it doesn't have an understanding of a source data_id. I'll have to fix
that. I'll probably split that command into cli.create and cli.update.