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.
I don't think there's a race condition given that the findAndDeleteProtectionNodeInBackground is being passed a reference to the ID it needs to delete. I will change to assign to a local variable and pass this to the findAndDeleteProtectionNodeInBackground method for clarity.