delete unused *opaque{} definitions from std.os.windows

[expikr]

AFAIK the following are vestiges;

pub const HBRUSH = *opaque {}; // used for gui window creation in user32
pub const HCURSOR = *opaque {}; // used for gui window creation in user32
pub const HICON = *opaque {}; // used for gui window creation in user32
pub const HINSTANCE = *opaque {}; // used just once for entrypoint in start.zig then untouched
pub const HMENU = *opaque {}; // used for gui window creation in user32
pub const HDC = *opaque {}; // used for gui window drawing ops in gdi32
pub const HGLRC = *opaque {}; // used for gui window drawing ops in gdi32

c.c. @squeek502

[squeek502]

I actually think this is one area where it might make sense to keep unused std.os.windows definitions due to how opaque {} works.

For example, say I'm writing some code that uses HICON and passes it to 2 different libraries foo and bar. With the definition in the standard library, that code could look like:

const foo = @import("foo");
const bar = @import("bar");

pub fn something(icon: std.os.windows.HICON) void {
    foo.fooIcon(icon);
    bar.barIcon(icon);
}

and

pub fn something(cursor: std.os.windows.HCURSOR) void {
    foo.fooIcon(cursor);
    bar.barIcon(cursor);
}

would give a compile error.

However, if the definition is not in the standard library, then usage might look something like this instead (assuming foo and bar each had their own HICON = *opaque {}):

const foo = @import("foo");
const bar = @import("bar");
// contains its own `HICON = *opaque {};` definition
const windows_extra = @import("windows_extra.zig");

pub fn something(icon: windows_extra.HICON) void {
    foo.fooIcon(@ptrCast(icon));
    bar.barIcon(@ptrCast(icon));
}

which loses the type safety of opaque {}.

Since the maintenance burden of these HANDLE definitions in the standard library is effectively zero (they'll never need to change), I think it might be worth keeping them around (and potentially expanding them to all common HANDLE types if there are any missing) for nicer interoperability.

Just my 2 cents though. #4426 might take precedence.

[expikr]

In that case, perhaps opaque types should be maintained in its own namespace std.os.windows.types instead?

The following resource handles are listed in https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types:

HACCEL
HBITMAP
HBRUSH
HCOLORSPACE
HCONV
HCONVLIST
HCURSOR
HDC
HDDEDATA
HDESK
HDROP
HDWP
HENHMETAFILE
// HFILE is legacy 32bit handle
HFONT
HGDIOBJ
HGLOBAL
HHOOK
HICON
HINSTANCE
HKEY
HKL
HLOCAL
HMENU
HMETAFILE
HMODULE
HMONITOR
HPALETTE
HPEN
HRGN
HRSRC
HSZ
HWINSTA
HWND

SC_HANDLE
SC_LOCK
SERVICE_STATUS_HANDLE