include blocking details when waiting for service up to invoke an effector on a child
effector invocations had been somewhat inconsistent in what failed -- the method call, the surrounding context -- this ensures that a programmatic call to invoke an effector will throw if it fails, that the effector task is added to any parent context, but as an inessential task so it does not fail the parent context.  new tests for this are in BasicEffectorTest.  the effect is particularly magnified when we attempt to add programmatically driven effector calls to the dynamic task context (so they show up in the gui).  these are now marked inessential, which i think is right because the user is interacting programmatically, and as the caller they would typically get on the result and handle errors themselves.

this largely preserves existing behaviour, apart from with the exception that effector method calls inside other effectors could previously fail without throwing, and now they throw.

this mainly affected dynamic cluster which in some places relied on failures being silently ignored, e.g. in the resize effector call.  this effector now reliably fails if the cluster does not resize.  previously it would depend whether it was in a task or not.  to preserve compatibility in that class as much as possible, some interface methods (non-effector) have had their signature changed.  it was not clear why these were on the interface, so i have deprecated them there also.
map target name to right format on cluster-level undeploy