feat: virtual multisigs

[harrysolovay]

Closes #658
Closes #555

This PR takes the learnings from #555 and integrates them into a VirtualMultisigRune. One can deploy a VirtualMultisigRune like so:

import { alice, bob, charlie, hex } from "capi"
import { VirtualMultisig } from "capi/patterns/multisig/mod.ts"
import { chain } from "polkadot_dev/mod.ts"

const state = await VirtualMultisigRune
  .deployment(chain, {
    founders: [alice.publicKey, bob.publicKey, charlie.publicKey],
    threshold: 2,
    deployer: alice,
  })
  .hex
  .run()

await Deno.writeTextFile("persist_this.txt", state)

To hydrate from the state hex, we do the following.

const vMultisig = VirtualMultisigRune.hydrate(chain, state)

To ratify a call from the stash account (signatory -> signatory proxy -> multisig -> stash), we can use virtual multisig's ratify method.

await vMultisig
  .ratify(bob.publicKey, proposal)
  .signed({ sender: bob })
  .sent()
  .dbgStatus("Bob ratify:")
  .finalized()
  .run()

Note: ensure that you've funded the proxy (as it's initialized with no more than the existential deposit –– fundMemberProxy)

Open questions:

• Should VirtualMultisig depend on mappings from the member accounts to the proxy accounts? This would allow us to avoid the DX of passing signatory index into the ratify method.
• Voting signatories in and out (how might we elegantly persist this data?)
• Validation such as threshold and existing member of vmultisig

[ryanleecode]

Dont we have codegen guard for these?

[harrysolovay]

We should avoid using codegened runtime code in patterns, as it makes them unusable to consuming NodeJS projects (for now).

[tjjfvi]

Closes #658
Closes #555

Can we go ahead and close those now, for housekeeping purposes?

[ryanleecode]

Proxy call needs to happen outside of ratify. We can't assume every ratify call will interact with the stash