Full multisig support

[rkalis]

Currently it is possible to use checkMultiSig in CashScript contracts. However, the CashScript SDK does not support redeeming multisig contracts. There are several reasons for this.

1. Multisig order matters, but the SDK doesn't know the order in which the signatures are used in the contract.
2. The CashScript SDK only uses Schnorr signatures.

To solve (1) we can enforce in the compiler that the order in which parameters are passed into a function is the same order in which they are used inside checkMultiSig. This way we know that the signing order is the same as the order in which the parameters are provided.

To solve (2) we need to either wait until the november hardfork and stick with only accepting Schnorr signatures. However, this means that CashScript can't be used with incompatible wallets. This is why we could optionally enable ECDSA signatures (#7), but I also like the idea of enforcing use of the best technology if you want to use CashScript.

[rkalis]

I've been thinking about this more. For the november hard fork, we need a way to specify the new checkbits to the checkMultiSig function. The easiest way on the implementation would be to add a checkbits parameter to checkMultiSig.

Another issue remains:
Currently, signatures are generated by the SDK during the transaction building process by passing in a signature placeholder: new Sig(keypair, hashtype). This allows a CashScript contract to be integrated into applications and wallets that have access to the user's keys (both custodial and non-custodial).

However, multisig applications don't fit in this paradigm as they need to be signed by multiple parties who won't share their keys with each other (this would defeat the purpose). So while we could fully integrate multisig into the current SDK, this would offer no practical value, as it still wouldn't allow users to easily enable multisig without sharing their keys.

A solution to this would be to add functionality and formalise a protocol for sharing partially signed CashScript (or general P2SH) transactions. An input script can require any number of different parameters, so this protocol needs to specify the expected position of remaining arguments among other things. The CashScript artifacts could be used for the specification of argument positions, but we still need a user-friendly way of sharing and completing these partial transactions.

It would be valuable to discuss this with many more people so this protocol can be used across multiple different applications and platforms. I spoke with @jcramer about a similar topic a few months ago, so it could be valuable to pick up that conversation again with some other people.

But for CashScript, I think there are some more important things that take precedence before this issue, like first-class support for SLP and for covenants.

[rkalis]

This issue is succeeded by the more general #124.