Lightning Network invoice compatability

[arshbot]

I initially made this PR -> https://github.com/slowli/bech32-buffer/issues/10 because I originally thought the solve would be a simple length check fix, however it seems there are a few more considerations required to ensure lightning network invoice compatibility.

The most important to mention is the removable of the following constraints:

1. mandatory prefixes
2. mandatory length if interpreted version bytes is 0 (0 by default)

And the addition of the following features:

3. HRP (Human readable part) field in the encoding window
4. Nullification of "Network" and "Script ver." if HRP isn't bc or tb

Rationale:

1. mandatory prefixes

Enforcing mandatory prefixes effectively enforces an only bitcoin address input, since lightning invoices do not have static hrp. For example, whereas for a testnet bitcoin segwit address you would see tb in the hrp, in testnet bitcoin lightning you'd see the network + the amount requested in the hrp - for example: tb20m representing 20 mbtc.

2. mandatory length if interpreted version bytes is 0 (0 by default)

This is more an implementation nit, if 0 is default then non bitcoin addresses are applied to this enforcement. This should be optional, not default.

3. HRP (Human readable part) field in the encoding window

The hrp represents important information that can't always be expected to fall into a prefix. Even though lightning has a standard, predictable template I think for a bech32 encode/decoder this should be more free in case other usecases for bech32 arise.

4. Nullification of "Network" and "Script ver." if HRP isn't bc or tb

Another implementation nit. If the network isn't bitcoin layer 1, these fields should be greyed out (nullified).

[slowli]

Couple of questions and suggestions regarding your proposal.

Regarding static prefixes: arbitrary prefixes are already supported when using encode / decode functions (as opposed to BitcoinAddress, which is indeed intended to be usable only for Bitcoin addresses). Would this be sufficient for the use case that you describe? Similarly, encode / decode already support encoding / decoding data of arbitrary length (subject to 90-byte limit, of course), and do not enforce any inner payload structure (such as script version).

Regarding "HRP in the encoding window", could you please provide an example or more details how this construction should look like?