Instead of separate types implementing the `Transaction` trait,
here we implement `Transaction` for a command type.
The definition of the `Transaction` trait ensures that:
* Implementations for commands with a particular extension
must be explicitly defined (that is, you can't just call
`transact()` with a random combination of a command type
and an extension type).
* The combination of the command type and the extension type
(via the `Transaction` impl) defines the response type
(both the command response and the extension response).
This definition means that:
* `Transaction` implementations for commands defined within
the epp-client crate that want to use an extension defined
within the crate must have an impl local to the crate.
* `Transaction` impls defined for commands foreign to the
epp-client crate as well as impls defined with extensions
foreign to the crate can have an impl in their defining crate.
This was being used in a few places where it was unnecessary.
Interestingly, it seemed that the deserialization logic in
`Request::deserialize_response()` was nesting `EppObject`s without
actually causing an error.
Dirkjan Ochtman
Nicholas Rempel