Address Index Support for Receiver<Monitor> State #1242

In #1218, we removed checking if the UTXOs have been spent from the check_payments function in the Receiver state, as the UTXOs can be spent in different transactions which would give false information on whether it was actually the Payjoin proposal which was broadcasted.

Instead, we added a new ReceiverSessionOutcome called PayjoinProposalSent. This session outcome signals that the monitoring of the Payjoin proposal has been skipped, because the original proposal contained non-SegWit inputs, which signals that the transaction ID of the Payjoin proposal will change once the sender signs it.

This raises the question: should the state be designed to allow for using clients with an address index, so that downstreams can implement a logic to check both SegWit and non-SegWit transaction broadcasts using the address index.

A couple of things that comes to mind:

1. Is there a common API among the clients which the closure signature can accommodate for?
2. Is it a better option to leave the current session outcome as is, and let the downstream check for the transaction outside the Payjoin session after they get the signal?
3. How would this change the reference implementations which use RPC (like payjoin-cli)? My thinking is that they would just skip the state and immediately return Success. check_payments would essentially short-circuit as it is currently doing but without the new outcome value -- just a Success.