Sensors chained for service up

This implements the use of service not-up indicators and problem indicators, as discussed on the ML.

See `service-state.md` for docs and `ServiceStateLogicTest` for detailed explanation and checking of subtleties.

The material differences in behaviour are surprisingly few (though in the PR you will notice a lot of changes to tests; most test changes are uninteresting!).  The main functional differences, in addition to dynamic updating, are:

* this removes a lot of ad hoc service-up computations; some quorum up logic e.g. for mongo,  has changed, but this was all quite hokey, we should replace this with quorum keys in cluster
* this tweaks a recent workaround where AbstractEntity.add{Enricher,Policy} detects a duplicate, we now take the more recent one rather than the older one; this allows us to replace them in a principled fashion when using unique tags.
* ServiceFailureDetector is now very different, and extends ServiceStateLogic (which previously is somewhat duplicated in the very occasional places it was used); if you were relying on this, or your apps start acting oddly, please let me know!


If the point of the class is to re-use it for subclassing then why the method returns a specific sub-class? There are similar cases for the other enricher builders, I can't see the reasoning.