CURATOR-79 - Modified the 'withProtection' handling, so that any failure

that is not a ConnectionLossException or other KeeperException is
treated the same as a ConnectionLossException. This means that if the
thread gets interrupted, or encounters some sort of other error, during
creation of a protected zNode, it will remove the affected zNode prior
to rethrowing the exception.

Exposed the debug UnhandledExceptionListener on the CuratorFrameworkImpl
to reproduce this issue via a unit test.
It can't be reversed. If it were reversed, the wrong ID would be passed. Maybe for clarity, a localProtectedId can be assigned and passed to findAndDeleteProtectedNodeInBackground()