WIP:Demonstrate failure handling with fallback TX broadcast

[zealsham]

As a refrence implementation , payjoin-cli needs to demonstrate proper fallback transaction handling in the case of payjon failure. From what i see , both sender and receiver can broadcast the fall back transaction , This pr starts by handling the sender side of things and would eventually progress to the receiver .

This is still a work in progress

this addresses #1156 .

• handle v1 sender broadcasting fallback
• handle v2 sender broadcasting fallback
• handle v2 receiver broadcasting fallback
• check that transaction is broadcastable before broadasting

Pull Request Checklist

Please confirm the following before requesting review:

• I have disclosed my use of
  AI
  in the body of this PR.
• I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.

[coveralls]

Pull Request Test Coverage Report for Build 19810689615

Details

• 14 of 54 (25.93%) changed or added relevant lines in 1 file are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.2%) to 83.296%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
payjoin-cli/src/app/v2/mod.rs	14	54	25.93%

Files with Coverage Reduction	New Missed Lines	%
payjoin-cli/src/app/v2/mod.rs	2	50.27%

Totals
Change from base Build 19686158876:	-0.2%
Covered Lines:	8991
Relevant Lines:	10794

---

💛 - Coveralls

[zealsham]

@arminsabouri i implemented error downcast method for v2 in this PR, the downside of this method is having to repeat the same block of code for the the different state of the senders session. I only did it for the "pooling proposal" phase of the sender session, i'll have to do it for the rest of the phases but just want to know your input on this before i head that direction.

i'm also simutaneously working on the "session outcome" based solution with the draft PR from you .