The existing CI has a step where it regenerates `rustls.h` using `make
src/rustls.h`, which in turn invokes `cbindgen`.

I'm seeing a diff created in CI that I don't see locally and suspect the
reason is a difference in `cbindgen` versions. To help debug this now
and into the future, this commit updates CI to print its `cbindgen`
version before performing the diff check.

CI is using the latest available cbindgen (0.24.5), which produces
a different formatted output than previous versions.

This commit regenerates the `src/rustls.h` header file using 0.24.5 to
match what CI expects, avoiding a CI failure from the detected diff.

Previously, building the tip of `main` in CI for Windows, Windows CMake
(Debug), and Windows CMake (Release) was failing with link-time errors
of the form:

```
rustls_ffi.lib(std-391022a4250a8b9a.std.feb3b897-cgu.0.rcgu.o) : error
LNK2019: unresolved external symbol __imp_NtWriteFile referenced in
function
_ZN3std3sys7windows6handle6Handle17synchronous_write17h5e143db420a86fa8E
[D:\a\rustls-ffi\rustls-ffi\build\tests\server.vcxproj]
```

The fix is to explicitly include `ntdll.lib` in the native static libs
that we link on Windows. Doing this fixes the builds once we also update
the `verify-static-libraries.py` script to expect this additional lib.

This may be related to an upstream `rust-lang/rust` change[0] but I'm
not 100% sure.

[0]: rust-lang/rust#108262

This commit does two things:

* In preparation for one day enabling merge queue on this repo, it adds
  `merge_group` as a trigger for the CI tasks.
* It adds a `schedule` trigger that will run the CI tasks weekly, to
  detect bitrot sooner than we might otherwise.

The `num_enum` dependency brings with it a large number of transitive
dependencies. Some of those transitive deps now have an aggressive MSRV
of 1.64+.

The existing usage of `num_enum` is very minimal: just one derived trait
for the `rustls_result` enum to provide it with a `From` impl for u32
primitive values.

This commit replaces the `num_enum` crate with a small
`u32_enum_builder!` macro rule loosely based on the Rustls
`enum_builder` macro. Since our use case is narrower, I've simplified
the macro and tailored it to the rustls-ffi use-case.

With the new implementation we can also drop the use of `try_from`. In
each case where we're converting from code -> result we're happy for the
default `from` impl's `InvalidParameter` variant to be used when given
an unknown code, making the use of `try_from` unnecessary.

This approach adds one complication related to `cbindgen`: it now has to
be instructed to expand the `rustls-ffi` crate before generating
bindings in order to find the `rustls_result` enum. Doing this requires
tweaking the `cbindgen.toml` to add a `parse.expand` configuration
setting. Notably this also means `cbindgen` now has to be run with a
nightly `rustc`. Since this is a developer only workflow it shouldn't be
too onerous a requirement.

We're now happily building with Rust 1.60 again and can also breathe
easy knowing we have a slimmer dependency profile!

tidy: replace rustls_result::try_from -> from.

In some instances (e.g. building the CMake configuration in debug mode
with the nightly rustc) the `--print native-static-libs` output of
`cargo build` can include many repeating instances of a lib.

While the order and duplicates are generally expected to be meaningful,
many consecutive duplicates are not.

This commit updates the `verify-static-libraries.py` script to collapse
consecutive duplicates before doing the check of expected vs actual.