`windows-bindgen` should generate more specific `Result<T, E>` types

[kennykerr]

Rather than folding all error types into the windows_result::Error type, APIs can more specifically return Result<T, HRESULT>, Result<T, NTSTATUS>, and so on. This would avoid the overhead that necessitated #3126 and allow simple pattern matching for error handling. The reasoning around the Windows-specific Result<T, Error> is that it additionally carries any IErrorInfo that may have been associated with the calling thread. This turns out to be used by very few APIs but can still be supported as needed through conversion.

[kennykerr]

One thing to keep in mind is that Result only really works well when there is one, or mostly one, success code. So it works fine for BOOL and it mostly works fine for HRESULT if you don't rely on nasty codes like S_FALSE but it doesn't work well for NTSTATUS in many cases because NTSTATUS has numerous codes, like STATUS_TIMEOUT, that are technically successful but in practice represent some kind of soft failure that would be lost if transformed into a Result.

[kennykerr]

Along these lines, I've been slow to add WIN32_ERROR to the windows-result crate partly because its not a "real" type in the Windows SDK but it now shows up quite prominently in the Win32 metadata and moving it formally in to the windows-result crate will simplify and formalize some typeless conversions that already exist inside windows-result and helps to enable this issue's goal of allowing windows-bindgen to generate more specific Result types such as Result<T, WIN32_ERROR>.

[ChrisDenton]

My only concern would be how accurate the metadata for WIN32_ERROR is if it's being inferred rather than coming directly from the SDK.

[kennykerr]

Yes, the flip side is to avoid transforming these signatures automatically and let the caller use foo().ok() if they really want the transformation to Result. And this works today. 😊