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.

UPDATE - ready for review and merging when appropriate

I have recently completed:

* Programmatic means of forcing transition from `FAILURE` to `STANDBY` or `HOT_STANDBY` (or `TERMINATED`) and from `MASTER` to `STANDBY`, `HOT_STANDBY`, or `TERMINATED`, and setting priority
* New `HOT_STANDBY` mode and `readOnlyRebind`
* 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)

We still need TO DO the following:

* 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)
* GUI/REST support to, at minimum, allow operators to access (after a warning probably) standby and failed servers, to display rebind problems, to set HA priority and force HA state changes -- this will allow us to design a sensible `BrooklynCluster` with failover!

But these can proceed independently; what is in this PR now feels like a complete package.
Could reassert `assertEquals(appRO.getAttribute(TestEntity.SEQUENCE), (Integer)3)` to be explicit that the value is unchanged.