By spending to a wallet address. The node must be started with
`-blindedaddresses=1`. I've configured it to be the default value
since we are always working with confidential transactions.

Doing the same for non-Bitcoin outputs is left as a TODO.

This is helpful because we sometimes need to peek at the next value
to deserialize the right thing.

The previous model was to flexible in that it allowed to express
states that were not actually possible (like explicit value but
confidential asset).

Make better use of the type system

The whole commitment is 33 bytes long with the last 32 bytes being
the x-coordinate of the public key.

The original asset commitment can always be retrieved from the
ConfidentalTxOut.

That is, most important to least important with increasing level
of detail based on the order you encounter the structs as you
read through the existing type definitions.

Order of `impl` blocks for traits are at the bottom but unsorted.

Be gone, wild byte arrays!

cc @da-kami

By providing two constructors for a ConfidentialTxOut, we can make
it easier for users to properly construct a valid transaction that
follows all the invariants that need to be upheld.

This also simplifies the calling site massively because we don't
have to iterate over the inputs several times.

We always pass random bytes in here, I think this is just used for
entropy.

We try to hide the actual wally APIs from the user by providing
meaningfully named functions on the actual types that we want to
construct.

Instead of accepting free-form entropy, we pass an rng argument
that makes it obvious that this function depends on randomness to
produce sane outputs.

This is more concise than calling `ok_or_else` if we are always
constructing an anyhow::Error anyway.

Format everything with dprint