[#907] Answer the review of the base DN change ordering

Keep the write confined to what a rollback undoes, and make what happens
outside it survive its own failures.

- Open the base DNs being added before deleting the ones being removed, so
  that the failure this operation is most likely to meet is reached while
  everything is still there to roll back to.
- When the write fails, ask the storage which of the removed containers
  actually lost their trees and give up exactly those. An engine which rolls
  a tree deletion back leaves the backend as it was; one which does not -
  cassandra, and the jdbc backend on mysql and oracle - would otherwise leave
  a base DN routed here with nothing behind it.
- Close an entry container whose registration failed only when the root
  container did not take it, since nothing else can reclaim one it did.
- Deregister, unregister and close a removed base DN together, rather than
  closing it in a finally which runs when the registry still routes to it.
- Derive baseDNs from what the root container ended up holding, on the way
  out of every path, instead of from the configuration that was asked for.
- Report the failures through backend.properties rather than a raw English
  string, name the base DN each one is about, and set adminActionRequired
  where a restart really is the remedy.
- Skip the locks and the transaction altogether when no base DN moves.
- Read rootContainer once, and say in EntryContainer.delete's javadoc what
  its contract actually is.