bip-taro-universe: flesh out capability for unilateral exit from pocket universe due to provable censorship

Nobody has claimed this yet.

There's an existing TODO in the BIPs for the Pocket Universe construct. At a high level, a Pocket Universe is a sort of Taro-specific federated sidechain. Parties can opt to "freeze" their normal assets in a top-level native Bitcoin transaction, then inhiert the capaubilities of cheaper aggregrated on-chain transfer byu doing them in a virtual transaction graph. This virtual trancstion graph is commited to th eUniverse, so parties can observer trnasfer,s and also prove ownership of transfers.

One issue with the current design is while operators can't _forge_ transfers (can't forge a digital sig), they can chose to omit commitments all together. With the current design, omitting a commitment ends up burning an asset, as that's an invalid state transition.

I've come up with a new idea, dubbed "exit portals". The idea is that rather than put their locked asset commitment in that top-level output controlled by the federation (?), they instead create an output on chain that allows parties to unilaterally exit from the pocket universe. This relies on the fact that if commitment N contains my asset, but commitment N+1 doesn't, then assuming I have the commitment data, I can create an inclusion proof for commitment `N` and an exclusion proof for `N+1`. I can then use the on-chain exit portal to regain full control of the asset, as we'd add additional VM state machine validation for this exit case.

In order to work properly this exit portal output needs to be created in the same transaction (?) as the initial pocket universe asset transfer. This trade off means it doesn't inherit the UTXO scaling properties (1 UTXO, unbounded amount of assets) quite like the existing concept did. However it may be possible to batch these outputs together, Coinpool style, enabled by anything CTV-like. Alternatively, it may be possible to retain the UTXO aggregation by having the initial entrance transaction a prior delegate another exiting output (or output descndent chain?) as the exit portal.

Related to https://github.com/lightninglabs/taro/issues/9

Start with the existing Pocket Universe TODO in the BIPs and read the related lightninglabs/taro issue. Work out the exit-portal design, including how inclusion and exclusion proofs trigger the on-chain exit validation and how the portal is created or batched. Done means the unilateral-exit capability and its trade-offs are specified clearly enough for implementation.

Written by the indexing model from the issue text.