Begin rollout of Nessy

This PR gets the Nessy rollout underway.  The basic steps for the rollout are:

1. Deploy code that can use Nessy (as a non-mandatory lock) when configuration directs it to (that's this PR).
2. Wait until no snapshots that cannot accept that configuration are active.
3. Set the Nessy configuration in genome.sh & monitor for problems.
4. Update code to make Nessy locks mandatory.
5. Wait until all active snapshots have mandatory Nessy locking in place.
6. Update code to turn off NFS-based locks.

The possible problems with this approach include:

- Users not using up-to-date configuration, therefore not having the Nessy configuration setup when we reach step 6.  This would cause some users to be exclusively using one system, while other users exclusively use the other.
- I don't know enough, but it might be that CLE configuration is coupled to our standard genome.sh configuration.

In this case, it would help if we could deploy snapshots as combinations of configuration + code rather than having shared configuration for all deployed snapshots and all checkouts.
`backends()` is always called in list context and always as a function so there is no problem.  However, `memoize`, by default, caches list and scalar context separately and would also cache the answer separately for a function call versus  a class method.  I don't know whether this is something we should worry about in the code or not but it's important to at least be aware of.  If one wanted to be paranoid you can turn on an option to merge scalar and list caching (favoring list context) and pass in a key normalizer that handled the unimportance of arguments, e.g. `$class`.

Or, as @acoffman would probably suggest, you could just do,

```
my @backends;
sub backends {
    return @backends if @backends;
    ...
}
```