[#907] Change the base DNs of a pluggable backend outside the write the storage replays

Storage.write requires its WriteOperation to be idempotent, because an implementation replays it
after a transaction conflict. applyConfigurationChange performed the registry work - which no
rollback reaches - inside that operation, so a replay half applied the change: the removal path
re-read the stale cfg and deregistered a base DN it had already deregistered, reporting an
UNWILLING_TO_PERFORM against the operator's own DN rather than the conflict; the creation path
skipped the DN its first attempt had registered, leaving a base DN registered with no trees at all
and reporting success.

The operation now only deletes and opens trees, which a rollback undoes, and the base DNs to remove
and to add are worked out ahead of it, so no attempt sees different work to do than the one it
replaces. The registries, baseDNs and cfg are updated once the write has committed. The entry
containers of a removed base DN are held exclusively across the write, since their trees are now
deleted while they are still registered.

ReplayedConfigChangeTest drives the replay from PDBStorage's own retry loop, so that every attempt
shares the storage implementation and the PersistIt exchanges a real conflict would.