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 Multiparty Senders: NS1R #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.