State UX improvements

[apoelstra]

Once #33 merges we will have the ability to attach state commitments to Simplicity programs. However, there are some ergonomic issues here because adding a state commitment (and changing the state) will change the generated address, and the user must invoke everything with a consistent state commitment to avoid bad things happening.

First,

• The output of hal-simplicity info should clearly indicate whether there is a state commitment alongside the CMR.

Then update-input has several ways it can be improved.

• The output of hal-simplicity update-input should warn if you provide an input UTXO but no CMR. (This is actually unrelated to state.)
• The output of hal-simplicity update-input should error if you provide state but no CMR (in this case currently it just silently ignores the state which is nasty)
• The output of hal-simplicity update-input should warn better if you provide the wrong/missing state. (The existing message is not bad, but it doesn't output the state.)

[schoen]

So for example, wallet software that repeatedly interacts with a contract that has changing state will need to calculate a new address for each such subsequent interaction?

Or in a shell script currently driving such contracts, I would call hal-simplicity info anew after each such transaction and get a new address for my next interaction?

The CMR value itself is deterministically derived from the contract independent of the state, right? Or is it actually committing to a tree that includes the state commitment?

[apoelstra]

Yes on all counts.

Or is it actually committing to a tree that includes the state commitment?

No, it's independent.

[apoelstra]

cc @delta1 @canndrew can I have an ACK? I think once we get this PR in it'll be okay to cut a release