Rollup merge of #162270 - ChrisDenton:winagain, r=clarfonthey

Update `windows-bindgen` to 0.100.0

This release represents a major change in the way bindings are generated. See https://github.com/microsoft/windows-rs/issues/4867 for details.

In short, it now more directly follows the C headers. For the standard library's purposes this is mostly reflected in relatively minor type changes or with some `const` pointers becoming `mut`.

There is however one big change that affects a lot of types. In the headers there are a lot of `#define`s like this:

```c
#define GENERIC_READ                     (0x80000000L)
#define GENERIC_WRITE                    (0x40000000L)
```

These are constants for the access mode. In this case they're explicitly declared as `L` (aka signed long) integer types (in other cases there's no type at all). However, this conflicts with how access mode constants are actually used. E.g., see `CreateFileW`:

```c
WINBASEAPI
HANDLE
WINAPI
CreateFileW(
    _In_ LPCWSTR lpFileName,
    _In_ DWORD dwDesiredAccess,
    _In_ DWORD dwShareMode,
    _In_opt_ LPSECURITY_ATTRIBUTES lpSecurityAttributes,
    _In_ DWORD dwCreationDisposition,
    _In_ DWORD dwFlagsAndAttributes,
    _In_opt_ HANDLE hTemplateFile
    );
```

Here `dwDesiredAccess` is a `DWORD`, which in rust equates to `u32`. The constant being signed but the usage being unsigned is not a problem for C/C++. They will happily convert between types at the drop of a hat. Rust however is stricter, as you know.

The old metadata used by `windows-bindgen` tried to try to fixup this mismatch but the new one goes strictly by what can be inferred from the headers.  The hope in the future is that the headers themselves will be updated so better bindings can be directly derived from them.