Support `Option<Trait>` (and `Option<&Trait>`, implemented the same)

Use new `Type`-based resolution to decide if a container is transparent

We also assert that we were able to resolve paths inside containers
as we shouldn't be deciding if a container is transparent without
all the context.

Use new `Type`-based generic resolution in `write_rust_path`

This gives us better generic resolution, but because we determine
whether to include a `crate::` prefix or not based on generic
resolution it means we have to pipe through the "type is a generic that
was resolved" flag from `write_rust_type`. We also take this opporunity
to do better decision making for the `crate::` prefix entirely, which
is important for enums that contain trait instances.

Pass `with_ref_lifetime` through to rust-type-printing from C-path printing

If we get to `write_c_path_intern` with `c_ty` unset, we delegate to
`write_rust_path`, however it would lose the `with_ref_lifetime`
flag, causing us to miss `'static` when printing references in
generic arguments. Here we simply pipe it through.

Check whether the fields of an enum are clonable before implementing clone

Do a second initial-walk pass to apply clonable flags to aliases

This enables the clonable flags for `*Features`.

Move code to map aliased types into a virtual impl block into a helper

This will allow us to create virtual impl blocks during the early
code passes before we go to do the full conversion pass.

Generate mutable references in `default_generics` when relevant

As we move towards resolving generics via the new `Type`-based
interface instead of the string-based one, we need to ensure we
retain the mutability flag when resolving references, which we do
here.

Move overly-specific check to an assertion where its relevant

Do not make `Deref<T>` generic params always a `&T` for traits.

We never expect traits to be passed by reference, so when using
the new-style generic resolution, we shouldn't force all `Deref`s
to `&T`, at least if the `T` is a trait.

Print field documentation even for unnamed enum variant fields

Add a note in output documentation for fields with refs to opaques

Because we (probably shouldn't, but do) map "opaque" structs with
an `is_owned` field instead of having a dedicated reference type,
fields which are a `Deref<Struct>` are simply mapped as
`OpaqueMappedStruct`. This is confusing for downstream `lightning.h`
consumers as they cannot differentiate between a field that expects
to own a `Struct` and one which expects to own a reference to it.

This is worked around here by adding documentation which can be
matched on, though ultimately structs should move towards full
ownership.

Set `ptr_for_ref` correctly when writing conversions for enum fields

Correctly set the `ptr_for_ref` arg on `write_c_type` calls in enum printing

This avoids adding references to opaque structs in enum fields,
where we should, of course, map them as owned opaque structs.

It does generate some difficult-to-parse-by-downstream-bindings
code, which is addressed in a later commit by adding documentation.

Note that it also relies on the types being mapped differently
being opaque as it now needs logic to map a reference to a
non-reference with `is_owned` unset.

Correctly define the `native` type alias for enums with generic params

Correctly generate `impl` blocks for traits with generics

Support `T: Deref...where` in underlying structs from type aliases

Handle trait methods with a default implementation

This does not currently expose the default implementation to users
who wish to avoid manually implementing the method.

Include the `where` clause from a "real" type when mapping type aliases

ie if we have a
```
struct A<T: Deref> where T::Target: Trait {}
pub type B<T> = A<T>;
```

this includes the `where` clause so that we end up calling
`writeln_opaque` for `struct B<T: Deref> where T::Target: Trait {}`
instead of `struct B<T: Deref> {}`.

Add where-clause generic params to `default_generics` map

This moves yet more generic resolution to being able to rely on the
`default_generics` map for full-`Type` resolution rather than
string-based name resolution.

Make panics in macros more debug-able by giving them a unique print

Support `use ...::self` imports

Previously we'd supported `use self:...` but this adds support for
using some path that ends with `self`.

Support arrays inside Option types

Previously we'd supported arrays in options only if the real type
was something which we'd aliased to an array, so its not a big
stretch to support Options containing arrays explicitly.

Add more manually-generated types to the on-startup clonable list

Update c_types `IOError` type to support `no-std` via `core2`

Add C type for bitcoin::util::address::WitnessVersion

Update `lightning-c-bindings` to new `bitcoin`/`secp256k1`

including new error types for `secp256k1::Error`

Update type mappings for bitcoin 0.28.1

Merge pull request #77 from jurvis/main

Use GNU sed if available on macOS

Check if GNU sed is available on macOS

Check if is_gnu_sed is true

Merge pull request #75 from TheBlueMatt/main

Fix M1 build

Add a warning before we run a ton of sed's

Skip building x86_64 release binaries on M1 Macs

Explicitly specify a target when calling local clang

This should fix using upstream x86_64 clang on an M1 Mac via Rosetta

Don't use -mcpu=native on aarch64-macos

Merge pull request #74 from TheBlueMatt/main

[ldk-net] Correct pollfds array offset after reads

[ldk-net] Correct pollfds array offset after reads

Previously, we were copying the pollfds array at an offset of one
into the handler thread's stack. However, when it was changed to
copying at a 0 offset (adding the pipe read fd at the end instead
of beginning), the disable-read handling code was not updated.

This leads to an assertion failure at runtime if LDK decides we
need to stop reading due to the outbound buffer of a peer being
full.

Merge pull request #73 from TheBlueMatt/main

Handle impl blocks outside of the mod of the being-implemented object

Drop now-unused code from c-bindings-gen

Update auto-generated bindings

Handle impl blocks exist outside of the mod of the being-implemented object

This allows us to implement the feature bit accessor functions.

Use full paths in impl block handling instead of assuming in-file idents

In the next commit we'll want to handle impl blocks in one module
for an object that is defined in a different model. This violates
several existing assumptions in the impl block handling code,
namely that we're implementing for an object declared in the
current module. This relaxes that assumption in a few places.

Merge pull request #71 from TheBlueMatt/main

Make `Str`'s `clone` always clone the underlying bytes

Make `Str`'s `clone` always clone the underlying bytes

Its incredibly unexpected that you can clone a higher-level object
(eg an Event with a ClosureReason that contains an `Str`) and have
a pointer back to the original object. To avoid this, `clone` needs
to actually `clone`.

Merge pull request #70 from TheBlueMatt/main

Expose consistent free+clone methods for `Bech32Error`

Update auto-generated bindings

Expose consistent free+clone methods for `Bech32Error`

Merge pull request #69 from TheBlueMatt/main

Update auto-generated bindings with FromStr errors

Send peers the remote address we have for them in ldk-net

The majority of this commit was authored by
Jeffrey Czyz <jkczyz@gmail.com>

Use `_none()` constructor instead of setting tag in C++ demo

Expose error types when implementing FromStr

Fixes #64.

Add additional error type conversion logic

Merge pull request #68 from jkczyz/2022-03-ldk-0-0-106

Update to 0.0.106

Update bindings workflow in CI to 0.0.106

Update auto-generated bindings to 0.0.106

Add a .gitignore for output of genbindings.sh

Update ldk_net.c for 0.0.106

Update demo.cpp for 0.0.106

Merge pull request #67 from TheBlueMatt/main

Redo tuple-reference mapping and prep for 106

Update auto-generated bindings

Crack `ReadableArgs` params when they're tuples

This replaces the special handling we'd had in 0.0.105.2 for
tuples-containing-references by instead just cracking open the
tuples and converting each field individually when calling
`ReadableArgs` where the argument is a tuple.

Revert "Consider all reference types clonable (because they are)"

This reverts commit 291aea2200e01843623a67d42112500b1810d276.

Revert "Manually handle generated types containing references to opaques"

This reverts commit 3798e35c9b8f23fa1500b8bc9867fef319287133.

Separate out CFLAGS for host builds and separate targets

This should at least fix one bug someone ran into trying to build
for Android from OSX.

Clone for `&Option<Enum>`

Push down type conversion logic around contained-has-inner some

Pin cbindgen as 0.21 broke the MSRV

Dont try to run valgrind on ppcel64 (it barfs on secp256k1)

Merge pull request #63 from TheBlueMatt/main

Consider all reference types clonable + handle refs-in-tuples

Update auto-generated bindings

Manually handle generated types containing references to opaques

This is really disgusting, we really shouldn't have references in
generated types at all, its just a mess. Instead, we should break
apart arguments when its a tuple, which would solve this more
cleanly.

Consider all reference types clonable (because they are)

Merge pull request #62 from TheBlueMatt/main

Expose ProbabilisticScorer in Bindings

Update auto-generated bindings with the ProbabilisticScorer

Switch to using the Prob. Scorer in the C++ demo

Allow method call args to be converted with a new_var conversion

The call was already there, not sure why we were asserting on it
not printing anything...

Pass types through `resolve_type` in a few additional places

Over time I'd like to swap all of our generic resolution to pass
through `resolve_type` instead of the current path resolution, as
its strictly more flexible, but for now we just add the few we need.

Separate printing references-with-lifetimes from c-vs-rust types

(and use C types with lifetimes in generic struct creation)

Process all type aliases as C types, leaning on annotations to skip

Previously we'd used the presence of generics on a type alias
definition to decide when to skip creation of a corresponding C
type. However, with `ProbabilisticScorer`, we now have a type alias
which has a generic bound but which we still want to create a C
type for.

Merge pull request #61 from TheBlueMatt/main

Implement `Clone` for `SecretKey`

Implement `Clone` for `SecretKey`

Merge pull request #60 from TheBlueMatt/main

Update to 0.0.105

Update bindings workflow in CI to 0.0.105

Update auto-generated bindings to 0.0.106

Update demo.cpp with latest upstream API

Explicitly refer to `format!()` with an `alloc` prefix for no-std

Add function-call generic parameters when they're resovable

We really shouldn't ever actually need to do this - rustc should be
smart enough to figure out what we're doing given all the
parameters are concrete types, but this appears to be failing
sometimes.

Handle `Option<[u8; 32]>`, mapping it same as `Option<&[u8; 32]>`

Don't mark everything with a feature bound as TestOnly

Convert slices containing non-primitives that are clonable

Update build for lightning-invoice no-std support

Recognize `bitcoin::bech32::u5` instead of only `bech32::u5`

Merge pull request #59 from TheBlueMatt/main

Detect aarch64-osx for using apple sed as well

Detect aarch64-osx for using apple sed as well

May fix #58, but there's probably other broken stuff around.

Merge pull request #57 from TheBlueMatt/main

Optimize more aggressively for WASM builds

Overwrite ldk_ver.h to avoid back-to-back builds duplicating consts

This causes back-to-back builds to have an ldk_ver.h for which the
oldest content dominates.

Stop passing -mcpu=sandybridge to wasm builds on x86

Use -O1 on WASM debug builds as they are otherwise too slow to run.

Drop `cargo rustc` in favor of using $RUSTFLAGS

cargo rustc only passes the given arguments to the linking rustc,
not any building rustc calls, which is not generally what we want.

This further reduces `liblightningjs_release.wasm` from 2.4MB to
2.3 MB.