Windows: Run compat_fn init before C++ init

[ChrisDenton]

Fixes #97814

This takes the first option on the above issue. Instead of using C++ initializer functions for dynamically loading Windows API functions, this uses C initializer functions. These will be run before C++ initializers, allowing third party code to be able to use pre-main initializers without having to worry that some function or other may not yet be available.

@rustbot label +O-windows

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

[bors]

☔ The latest upstream changes (presumably #99553) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[ChrisDenton]

Rebased. The other PR addressed many of the problems in the original issue by making sure we depend less on the initializer having already been run. But currently WaitOnAddress and WakeByAddressSingle still must be manually initialized before use. So this PR runs our init earlier, hopefully before any user init functions are run.

r? @thomcc since we were talking about something related.

[ChrisDenton]

I'm closing in favour of #100127. Though I may reopen if that isn't merged.