compile_tr: emit Or branches as separate Tapleaves instead of OP_IF/NOTIF

[kwsantiago]

The policy compiler's Taproot path currently compiles Or branches into single Tapleaves using OP_IF/NOTIF, carrying over the P2WSH pattern. In Tapscript, the Taptree itself provides a branching mechanism via separate leaves.

For simple policies, decomposing Or branches into separate leaves can improve privacy (only the spent leaf is revealed on-chain). For complex policies (e.g. large conjunctions of ors, or high-k thresholds), full decomposition is impractical due to combinatorial explosion, so a max_leaves cap is provided.

Proposed approach: add compile_tr_native() as an opt-in alternative that decomposes Or/Thresh at the policy level, compiles each branch to an IF-free leaf using the existing Tap compiler, then assembles an optimal Taptree via Huffman coding.

[apoelstra]

This improves privacy (only the spent leaf is revealed), produces more efficient witnesses for common spending paths

I agree that it would be privacy-maximizing to always use tapleaves. But it's not always more efficient (and in some cases it would be so inefficient as to be unworkable). For example, consider a conjunction of 64 or()s. If we were to do a full tapleaf decomposition we'd need to construct 2^64 leaves which would be extremely computationally intense (and very hard to find any storage for the resulting descriptor).

For thresholds the situation is similar: a 13-of-20 threshold has 125970 branches if you were to expand it all the way.

and aligns with BIP-341's design intent.

I mean, BIP 341 also includes the CHECKSIGADD operator whose express intent was to do threshold signatures directly in Script.