Upgrade bech32 dependency

[optout21]

Update: Obsoleted by #3244 ( #3201 ) .

Fixes #3176 .

Changes summary:

• Upgraded bech32 dependency to 0.11.0
• Crates affected: lightning and lightning-invoice
• The previously used type bech32::u5 has been discontinued, but bech32::Fe32 can be mostly used as a replacement (except eg. Ord).
• bech32::Error is mostly replaced by bech32::primitives::decode::CheckedHrpstringError
• To/FromBase32 for Bolt11InvoiceFeatures and PaymentSecret moved to lightning-invoice crate

Here are some minor issues identified

• Fe32 does not have Default and Ord, for which some workaround is needed (see Add Default trait to Fe32 rust-bitcoin/rust-bech32#187 Add Ord trait to Fe32 (derived) rust-bitcoin/rust-bech32#186)
• Fe32 is used in many places (e.g. as parameter), which is not very optimal, as it is an external type. The InvoiceData wrapper type was created to mitigate this to some extent.
• Conversions of bech32 error types are not always optimal
• Parsing of tagged values in an invoice remains own implementation (not supported by bech32 crate)

TODO:

• Further upgrade from 0.10 to 0.11 (should be smoother)
• fix fuzz target
• squash

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 83.91960% with 32 lines in your changes missing coverage. Please review.

Project coverage is 91.01%. Comparing base (78c0eaa) to head (b9d2ccb).
Report is 63 commits behind head on main.

Files	Patch %	Lines
lightning-invoice/src/lib.rs	38.09%	13 Missing ⚠️
lightning-invoice/src/ser.rs	89.53%	1 Missing and 8 partials ⚠️
lightning-invoice/src/de.rs	94.20%	1 Missing and 3 partials ⚠️
lightning/src/offers/parse.rs	63.63%	2 Missing and 2 partials ⚠️
lightning/src/sign/mod.rs	50.00%	0 Missing and 1 partial ⚠️
lightning/src/util/test_utils.rs	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3181      +/-   ##
==========================================
+ Coverage   89.80%   91.01%   +1.20%     
==========================================
  Files         121      121              
  Lines      100045   110610   +10565     
  Branches   100045   110610   +10565     
==========================================
+ Hits        89845   100668   +10823     
+ Misses       7533     7422     -111     
+ Partials     2667     2520     -147     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[TheBlueMatt]

Awesome, thanks for working on this. Will let @arik-so work with you here since he was also looking into this.

[optout21]

Ready for review.

[arik-so]

now that we have this InvoiceData wrapper around a [Fe32], do you figure it's worth also creating one for an individual value? Using finite field value constructors seems like it might have separation of concerns potential, but it's not that much different from what we'd been doing prior, just more explicit.

[optout21]

Yeah, it's possible to have an own type (I would keep the u5 name), and only reuse the char conversion logic from the external bech32 crate. But event that is rather small logic, could be completely taken over.

[optout21]

I concluded at least for the u5 type an own implementation is justified, I plan to do this. That would also reduce the diff of this PR quite a lot.
Other logic parts could be eventually taken over (as I have described in #3195 ), but for now the u5 type should be fine.

[arik-so]

Sounds good!

[optout21]

This PR is now replaced by #3201, where there is some own implementation (for u5).

[optout21]

This has been redone following #3234 , now in #3244 .