simplicity: minimal simplicity descriptors support

[KyrylR]

This PR bumps rust-simplicity version to the last one which in result bumps MSRV

Because of the MSRV bumped some formatting/clippy changes were introduced as well

The idea behind is to add minimal working Simplicity descriptors (which in this cases means CMR descs only)

Satisfaction of SImplicity desc was removed entierly because it requires ElementsEnv, so to keep the scope of this PR minimal will tackle the satisfaction of Simplicity desc in follow up PRs if necessary

[delta1]

ACK 2cfd000; tested locally

Nits / follow-up suggestions (non-blocking)

• Pre-existing bug now dead code (src/simplicity.rs:38-39, 46-47): the and/or parsers set right = Policy::from_tree(&top.args[0]) (should be args[1]). This predates the PR and is now unreachable via descriptors (non-asm leaves are rejected), but the buggy impl_from_tree still exists. Consider fixing or removing the unreachable and/or/thresh/pk arms while restricting scope to CMR-only, to avoid shipping latent-wrong code.
• lift() still panics (tr.rs:820-821) on a SimplicityLeaf. Reachable via public .lift(). Returning an Error would be more consistent with the PR's move away from panics, but arguably out of scope.

[KyrylR]

Nits / follow-up suggestions (non-blocking)
Pre-existing bug now dead code (src/simplicity.rs:38-39, 46-47): the and/or parsers set right = Policy::from_tree(&top.args[0]) (should be args[1]). This predates the PR and is now unreachable via descriptors (non-asm leaves are rejected), but the buggy impl_from_tree still exists. Consider fixing or removing the unreachable and/or/thresh/pk arms while restricting scope to CMR-only, to avoid shipping latent-wrong code.
lift() still panics (tr.rs:820-821) on a SimplicityLeaf. Reachable via public .lift(). Returning an Error would be more consistent with the PR's move away from panics, but arguably out of scope.

Yep, know about those, will address them in later PRs

[KyrylR]

Converted to draft because of this: BlockstreamResearch/rust-simplicity#376 (I am relying on assembly here, so I would need to revise logic)