[WIP] Rebind read only

The guts of the changes to support a read-only / hot-standby mode for management.

The design minimizes code changes and lends itself to being adapted for multiple masters looking after different entities.

For review only at this point; still I'd like to:

* Have a property determining whether default is `STANDBY` or `HOT_STANDBY`
* Failure on `HOT_STANDBY` moves to `FAILURE` mode
* Support `BrooklynObject` replacement on subsequent rebind (and unmanagement when items removed)
* Ensure `BrooklynObject` unmanagement and cleanup on demotion (this probably doesn't happen)
* Programmatic means of forcing transition from `FAILURE` to `STANDBY` or `HOT_STANDBY` (or `TERMINATED`) and from `MASTER` to `STANDBY`, `HOT_STANDBY`, or `TERMINATED`.
* Prevent activity for policies, feeds, enrichers, etc (possibly by promoting `suspend`/`resume` to `EntityAdjunct` and `AbstractEntityAdjunct` and in the latter checking the RO status of the entity; this won't catch everything but should catch most and make it easier to refactor those things which attempt a scheduled task inside `setEntity` ... that's not quite the answer, but in that direction I feel)

Subsequent to this we'll need some GUI/REST support to, at minimum, allow operators to access (after a warning probably) standby and failed servers, to display rebind problems, and to force a state change.

That will allow us to design a sensible `BrooklynCluster` with failover.
Longer-term (e.g. if writing something that we think should be the structure for a federated brooklyn, with different entities managed at different nodes), then I'm not comfortable wit the `EntityProxyImpl` being given a pointer to a `final Entity`. It should be to a "forwarding-entity" of some description, that can then be switched out for the real entity.

But for the short term (i.e. when only use-case is read-only mirror), I think I'm hesitantly ok with this.