Allow windows, windows_core (and several other crates) to be compiled and used in no_std environments.

[sivadeilra]

This allows many of the crates in this repo to be compiled and used in #![no_std] environments. This is a requirement for some low-level components, especially within the implementation of Windows itself.

These crates are updated: windows, windows-core, windows-registry, windows-result. All of these crates now define a new feature, std, which is enabled by default. If you disable the std feature, then the crate will be compiled with #![no_std]. Because the std features are enabled by default, existing users of these crates should not see any difference in behavior.

Nearly all of the changes are extremely simple and do not change actual codegen. These just convert std::ptr::null_mut with core::ptr::null_mut, etc.

For those cases where a crate used dynamic memory containers (Box, String, Vec), I added an explicit dependency on the alloc crate and imported the needed types. These are the same types that are re-exported from std, so this also has no effect on codegen.

In a few cases, code was using things from std that are currently only available in std, such as OsString or Mutex. In those cases, I placed the code using those items under #[cfg(feature = "std")]. Since the std feature is enabled by default, this will not break any existing users of those crates.

I also noticed a bug in passing in BasicString. It can construct a &[u16] over a null pointer, which is UB. I've fixed that bug in this PR.

[dpaoliello]

Suggested change

	std = []
	std = ["windows-result/std"]

[sivadeilra]

Actually, the more I think about feature injection, I think we don't actually need it unless A-->B where A actually uses something from B's std-dependent exterior API.

[dpaoliello]

In which case, we should check each crate with no default features to make sure we don't miss dependencies

[kennykerr]

• I think windows-registry could be entirely no_std.
• I could separately add a generated yml workflow for testing no default feature builds.

[sivadeilra]

Yeah, I see what you mean. I'm a bit concerned at the combinatorial explosion in A{no_std?} --> B{no_std?} variations, so I'm not sure how to implement this suggestion without things blowing up. But it's definitely a valid concern...

[kennykerr]

So I think the windows-registry crate doesn't need features of its own, depends on the windows-result crate with default-features = false, and can be #![no_std].

[sivadeilra]

Agreed. I've removed the feature from windows-registry; it is now always no_std (except in test builds).

[kennykerr]

Looks like this has been addressed with some follow-up work. Will merge now to get this batch of changes in.