Don't fail when deserializing a parentless HD key having depth greater than one

Currently, deserializing an HD key will fail if both (1) the parent object is null, and (2) the hierarchy depth is greater than one.  This patch changes that; rather than throwing an exception, the (null) parent is considered to be the root of the deterministic hierarchy.

*Note*: I am not an HD-Key expert and there may be a good reason not to do this of which I am ignorant, or there may be a better way to accomplish the same end.  That said, I don't see the benefit of causing a failure when deserializing an HD key just because I lack the parent, since that is the normal state of affairs when working with a listening wallet, the whole point of which is to provide some increased security by limiting the portion of the key hierarchy that is on one machine.  Furthermore, if it's wrong to deserialize a key that lacks a parent then perhaps the deserialization method ought not to accept a null `parent` parameter.  The current state of the code seems to be based on an unstated assumption that a missing parent is acceptable as long as the path is known, and if that is the case I'm interested to know why.  If not, then the raised exception seems only an unnecessary hindrance to usage and this patch may be warranted.

Another way I can think of to deal with this issue would be a method in the `DeterministicKey` class that returns a clone of the key with the path removed.  That would mean the client has to intend explicitly to change the path of the parentless key, rather than having it happen automatically as this patch does.  However, the same intention seems to be indicated by passing a null `parent` object to the `deserialize` method, so the way I've done it here seems to be a simpler way of achieving the same thing.