Distributed PSBT construction

[nothingmuch]

rough draft of a BIP discussing when and how PSBTs merging is a join semi-lattice

this is the basis of state machines of the honest (#4), semi honest and BFT variants of multiparty transaction construction, and ensures these protocols do not depend on all peers observing a consistent ordering of protocol messages which simplifies coordination

TODO:

• various TODO comments
• diagrams, examples
• discuss how bip 370 state machine precedes to the bip 174 state machine, and similarly this precedes bip 370 state machine (states closer to the terminal state can be represented with lower PSBT versions)
• discuss tradeoffs of of PSBT_GLOBAL_TX_UNORDERED as an indicator that the order is random vs. PSBT_GLOBAL_UNORDERED_{INPUT,OUTPUT} with keydata and the input map serialized in the value
  • pro PSBT_GLOBAL_TX_UNORDERED marker and backwards compatible input/output maps:
    • unordered marker matches joinpsbt behavior
    • unique identification semantics are closer to BIP 370
    • only one logical place for authoritative input or output data
  • cons:
    • combine "just works" for unordered fields in this representation if done recursively, even with BIP 370/174 rules for legacy combiners, exploiting the fact that unique id under the old rules is meaningless
    • ambiguous if both positional and keyed input/output data is included, possible safety issue if conflicting due to unintentional forwards compatibility for older implementations