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.
Is there a possible race condition between issuing the background delete and reassigning the protectedId? I almost think we would want to swap the order. (Intuition only, no concerete examples of this).