Clarify Mandatory Field Length Requirements and Add Note on Low R Signatures in BOLT 11

[nGoline]

This PR addresses the ambiguity in BOLT 11 regarding the handling of mandatory fields (p, h, s) when their lengths are incorrect. Specifically, it clarifies that:

• A reader MUST fail the invoice if a mandatory field (p, h, s) is present with an incorrect length, rather than skipping it. This ensures that invoices with invalid mandatory fields are not misinterpreted as valid.

Additionally, this PR adds a note to the examples section regarding the use of Low R signatures. While Low R signatures save 1 byte in DER-encoded signatures, they are not enforced in the specification. This clarification is added to help implementers avoid confusion when testing against provided vectors, as the test vectors do not enforce Low R.

Changes

1. Updated the "Requirements" section to explicitly state that invoices must fail if mandatory fields have incorrect lengths.
2. Added a note to the examples section explaining that Low R signatures are not enforced in the specification, even though they can save space.

Context

This PR resolves the ambiguity raised in #1235. The issue highlighted a potential misinterpretation where a p field with an invalid length could be skipped, leading to an invalid invoice being treated as valid. It also addresses confusion caused by test vectors not enforcing Low R signatures, which caused discrepancies during testing with libraries like NBitcoin.

Testing

• Verified that the clarification aligns with the behavior of major implementations by running a Differential Fuzzing.
• Updated documentation to ensure consistency with the clarified requirements.

[t-bast]

LGTM, ACK 60cc3b9 👍

[morehouse]

On the writer side, the requirement is to have exactly one d or h field present, so if we make this change on the reader side we should also fail the payment if both d and h are present.