Add an EtwDriverProvider for Windows kernel-mode support.

[NateD-MSFT]

Today, this repo relies on the user-mode Windows APIs for enabling ETW tracing. While this is all fine and dandy in userland, as we continue to invest in Rust support for kernel-mode components this naturally blocks us from using this crate to run ETW tracing in Rust drivers.

To alleviate this issue, this PR introduces a new EtwDriverProvider implementation of the Provider trait. Fortunately for us, the driver API for tracing is almost 1:1 with the user-mode API, which means EtwDriverProvider.rs is largely copied and pasted from the existing provider.rs implementation. Then we just genericize the macro generation a bit and we're good to go.

The biggest complication here is actually related to building. We need a dependency on the wdk-sys crate (see https://github.com/microsoft/windows-drivers-rs) to successfully build and link the kernel-mode DDIs. However, building this crate requires a full Windows Driver Kit installation and LLVM. We obviously do not want that to become mandatory for all developers to install to use the user-mode aspects of this crate.

As such, this PR introduces two new features to win_etw_provider and win_etw_macros: windows_apps, which is a default feature, and windows_drivers, which is not. Building the driver-related components is locked behind CFG gates for windows_drivers being active and windows_apps not being active. Thus the only way to activate the driver support - and the WDK requirements - is to explicitly opt in to the windows_drivers feature and to opt-out of standard behavior. This prevents this change from breaking existing workflows, but it does mean that building the driver support becomes a specific separate case from building the crate normally and not a standard additive feature.

An additional caveat: the GitHub automation will not automatically build driver support, as we would need to spin up WDK images as well. This isn't impossible (again, see windows-drivers-rs) but would significantly complicate this PR.

[NateD-MSFT]

@sivadeilra Review when you have a chance? The feature gating I've landed on here is a little messy. Perhaps it makes more sense to split this into a separate crate entirely?

[riverar]

An additional caveat: the GitHub automation will not automatically build driver support, as we would need to spin up WDK images as well.

This shouldn't be an issue. GitHub runners already have the WDK preinstalled.

[sivadeilra]

Rather than having a different proc macro, I think it would be better to have a single proc macro that generated code that would work for either user-mode or kernel-mode. If necessary, that code could use macros (not proc macros, ordinary macros) that are defined in win_etw_provider to handle some specialization for the environment.

I haven't skimmed the PR enough to see how different the output code is per environment, but my hope is that this can be unified.