Correct binding properties of Bitcoin eventuality

Eventualities need to be binding not just to a plan, yet to the execution of
the plan (the outputs). Bitcoin's Eventuality definition short-cutted this
under a honest multisig assumption, causing the following issue:

If multisig n+1 is verifying multisig n's actions, as detailed in
multi-multisig's document on multisig rotation, it'll check no outstanding
eventualities exist. If we solely bind to the plan, a malicious multisig n
could steal outbound payments yet cause the plan to be marked as successfully
completed.

By modifying the eventuality to also include the expected outputs, this is no
longer possible. Binding to the expected input is preserved in order to remain
binding to the plan (allowing two plans with the same output-set to co-exist).

coins/bitcoin/src/wallet/send.rs

@@ -232,6 +232,11 @@ impl SignableTransaction {
     })
   }
 
+  /// Returns the outputs this transaction will create.
+  pub fn outputs(&self) -> &[TxOut] {
+    &self.tx.output
+  }
+
   /// Create a multisig machine for this transaction.
   ///
   /// Returns None if the wrong keys are used.