Try preserving privacy for transactions greater than 2 outputs

[arminsabouri]

When the receiver selects optimal inputs, they use the try_preserving_privacy function to choose an input in a way that avoids triggering the Unnecessary Input Heuristic (UIH{1|2}). Currently, privacy-aware input selection is only supported for transactions with exactly two outputs. The motivation for this ticket is twofold:

1. Increasing the Anonymity Set: As explained in Unnecessary Input Heuristics & PayJoin Transactions, limiting payjoin transactions to two outputs inadvertently reduces the anonymity set as n-input-m-output payments become more common.

In its current state, PayJoin is only described for transactions with more than one input and two outputs. This leads to an anonymity set of 15.4% compared to the total number of transactions according to our extracted data for September 2020 (Figure 2). Moreover, it appears that classical payment transactions have been decreasing over the past years. Therefore, PayJoin should also be extended to transactions with more than two outputs to increase the anonymity set. As one of the main contributions of PayJoin is breaking the common input ownership heuristic, it can also poison the heuristic for a larger set of transactions.

2. Support for Multiparty payjoins / NSMR. Even when N is small the number of outputs are generally greater than 2. Currently #434 just picked the first candidate input.

Relaxing the 2 output requirment is easy enough and we should still be able to overcome UIH2 heuritic. However, we will be sacrifising the somewhat stealthy tx structure of payjoin. Per the quote above this might be a worthwhile sacrifise. We could also consider relaxing this requirment only in the multi-party context.