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!


setting expected state is also valid.  it just means it will get cleared on a stop or start/restart.

still not sure what best way is, in other places you may have seen, i used the `START` effector as a problem indicator, and cleared it when starting/stopping.  neither felt perfect, tho neither felt that bad.  thoughts?  (happy to leave for subsequent PR.)