Fix send::PsbtContext / send::multiparty::PsbtContext discrepancy

[DanGould]

The TODO on send::multiparty::PsbtContext::process_psbt

The problem with this [function] is that some of the inputs will be missing witness_utxo or non_witness_utxo field in the psbt so the default psbt.fee() will fail

I don't think that needs to be true, since this is processing a fully formed response from the receiver after having seen original PSBTs from $n$ senders. Since each of the senders includes full UTXO data, the receiver could return that too.

In a ns1r the receiver will not sign any inputs of the optimistic merged psbt

This seems like the real problem: the current checks will throw errors if the inputs of the optimistically-merged psbt are not finalized. The way to fix this is by separating the finalized-input checks from the other shared checks in the shared PsbtContext, which is really common Sender or send::Context akin to the receiver's SessionContext imo.

I think this would fix the comment in #847 (comment)

rust-payjoin/payjoin/src/core/send/multiparty/mod.rs

Lines 220 to 231 in 26eff9b

	impl PsbtContext {
	fn process_proposal(self, mut proposal: Psbt) -> InternalResult<Psbt> {
	// TODO(armins) add multiparty check fees modeled after crate::send::PsbtContext::check_fees
	// The problem with this is that some of the inputs will be missing witness_utxo or non_witness_utxo field in the psbt so the default psbt.fee() will fail
	// Similarly we need to implement a check for the inputs. It would be useful to have all the checks as crate::send::PsbtContext::check_inputs
	// However that method expects the receiver to have provided witness for their inputs. In a ns1r the receiver will not sign any inputs of the optimistic merged psbt
	self.inner.basic_checks(&proposal)?;
	self.inner.check_outputs(&proposal)?;
	self.inner.restore_original_utxos(&mut proposal)?;
	Ok(proposal)
	}
	}

related: #809.

IMO this would have been cleaner to write as an independent fn process_proposal(ctx: PsbtContext, proposal: Psbt) instead of wrapping the 'inner' PsbtContext but that's a secondary concern that can be addressed at the same time.