Use a linear range QuorumCheck to fail if there are too many dangling references.

This introduces QuorumChecks.newLinearRange which allows specifying points in a place
to define a set of line segments defining the quorum.
This can be TypeCoerced from a string, e.g. `[[5,5],[10,10],[100,70],[200,140]]`
(with things like `all` and `atLeastOne` also supported).

Such a range is then used to cause rebind to fail if there are a lot of dangling references.
The precise number is allowing 2 for small values, scaling to 5% at big values,
but this can be tweaked using RebindManagerImpl.DANGLING_REFERENCES_MIN_REQUIRED_HEALTHY
aka rebind.failureMode.danglingRefs.minRequiredHealthy .  (e.g. set this to all in
brooklyn.properties to cause rebind to fail if there are any dangling references;
but note this can occasionally fail if something is deleted as different items are
not persisted simultaneously).

Also:
* There are also some tidies to how `RebindContext` is used, since many of the
  dangling references weren't being caught
* We are stricter about persisting proxies, since that doesn't work (type written as `$Proxy16`)
* We tolerate remote timestamps in persisted objects (since these can occur in backups, currently);
  we don't *use* those timestamps for anything (except in tests when they can be `prefer`red),
  but there is no harm in having them, if someone copied across backup persistence files
Add a HOT_BACKUP mode where nodes are read-only copies but NOT willing to be master.
Make metrics on rebind, persistence, and HA available through REST API.

So that a management plane or human can determine server health and historic problems.