New test which reveals an ID deletion bug.

Thanks to @jimallman for pointing out that this was a likely
problem spot!. The ID should not be removed from the
study2shard_map unless the commit merges to master! (bug not fixed
with this commit)
corrected version of the test
bug fix: only removing study ID from mapping when merged to master
More thorough tests

Makes sure that a study ID disappears from the index when
deleted, but you can still fetch an old version of it.
Reinstating it is still not tested.
bug fix for deleting study ID + getting old copy

If the study ID is not found in the study_id2shard map, then
a simple rule to look up the shard based on the prefix is used.

This works, because the shard does not actually need to list the study
in its study_id2file_path mapping - it knows the filesystem location
to check. If there is no content there, then we know that (for the
commit SHA requested) that study did not exist.

Implementing this lets us retrieve old versions of deleted studies
using the phylesystem-api.

WARNING: should we ever deploy multiple shards with the same prefix,
the fallback mechanism of using the prefix to designate the shard
will not work. We'll probably just move to a system of ranges
at that point (ot_0 - ot_3000 in this shard, ot_3001 - in the other
one). This fallback code in phylesystem_umbrella get_shard will
need to be tweaked based on what we decide to do then.

OUTSTANDING issue: recommitting a study does not put it back into
the study_id2shard mapping. So such studies won't appear in the
study_list web service call. We actually use the list from OTI, so this
is not a major problem. You'll still be able to GET a reinstated study,
it just won't be in the fast dict (or any routine that relies on that
such as iterating over all studies in a peyotl.phylesystem interaction).
This is not used in the phylesystem-api AFAIK, so not a huge deal...