[BIP Proposal] Add sp() output descriptor format for BIP352

In a detailed exploration of Bitcoin wallet functionality enhancements, the discussion centers around the proposal to add block height as a parameter to reduce scanning burden for users. However, it's argued that since users can already specify a "wallet birthday" which serves a similar purpose and considering that scanning from the taproot activation height is feasible, adding block height to the descriptor might not offer significant benefits. This approach is somewhat questioned as other descriptors do not incorporate this feature, suggesting a preference for consistency across wallet functionalities.

Further analysis delves into the specifics of enhancing recovery strategies for Bitcoin wallets, particularly focusing on the management of BIP352 labels. The current method involves scanning for additional labels with an implicit inclusion of the change label (m = 0). A notable suggestion from the Bitcoin BIPs on GitHub proposes a strategy to streamline the recovery process by potentially limiting the maximum number of labels a wallet needs to scan, thereby simplifying fund recovery without necessitating the inclusion of an integer for label identification.

The conversation also introduces an alternative to new scan and spend key formats by proposing the usage of "sp(scankey,spendkey)" as a more streamlined approach. This suggestion aims to avoid the complications associated with introducing two new key expressions: one encoding the scan private key alongside the spend public key, and another encoding both the scan and spend private keys. Through these points, the dialogue encapsulates a broader debate on optimizing Bitcoin's wallet design for efficiency in scanning and fund recovery, while weighing the merits of maintaining existing conventions against the potential for innovative but complex solutions.