Extend API to allow invoice creation with a description hash

[joostjager]

Fixes #325

[tnull]

Thanks! Looks pretty good, but I think we can clean it up a bit further if we follow the approach of #434. Let me know if I should tackle that in a follow-up though!

[tnull]

Let's move this type definition to uniffi_types.rs directly.

[tnull]

I think rather than duplicating all of these, we should be able to follow the same approach as #434, i.e.,

a) add a local type alias

use lightning_invoice::Bolt11InvoiceDescription as LdkBolt11InvoiceDescription;

#[cfg(not(feature = "uniffi"))]
type Bolt11InvoiceDescription = LdkBolt11InvoiceDescription;
#[cfg(feature = "uniffi")]
type Bolt11InvoiceDescription = crate::uniffi_types::Bolt11InvoiceDescription;

above and have the receives use a macro like this:

macro_rules! maybe_convert_description {
	($description: expr) => {{
		#[cfg(not(feature = "uniffi"))]
		{
			$description
		}
		#[cfg(feature = "uniffi")]
		{
			&LdkBolt11InvoiceDescription::try_from($description)?
		}
	}};
}

(could also consider using it in the receive_inner/receive_via_jit_channel_inner, but the former is reused in unified_qr, which complicates things. So probably easier to do the conversion before giving the description to the _inners).

[tnull]

I double checked this as it confused me that it be possible to omit docs here. And indeed it doesn't work: note that if you run cargo doc --features uniffi --open, all the receive variants wouldn't have any docs on them.

For non-Uniffi we forbid missing docs on a crate-wide level (see top of lib.rs), but unfortunately we can't do this under the uniffi feature as some of the generated code doesn't have docs on it, which would have the deny(missing_docs) lint fail. This is why we didn't catch the missing docs at build time with the uniffi feature.

[tnull]

Feel free to undraft.

[tnull]

Flaky python test is pre-existing. Going ahead and landing this.