Stop building and alias winxpgui + fix ietoolbar demo

[Avasam]

As mentioned in https://mail.python.org/pipermail/python-win32/2024-March/014879.html

there's no longer a need given we no longer support XP at all. However,
for backwards compatibility we can't really drop the names - IOW, these
could all technically be rolled into a single .pyd, but from winxpgui import foo must continue to work somehow for all foo it worked for in
the past.

I went the very simple (and fast to "compile" 😉 ) route of having a pure python module that re-exports what we need.

>>> import winxpgui
>>> import win32gui
>>> import win32console
>>> winxpgui.GetConsoleWindow is win32console.GetConsoleWindow
True
>>> winxpgui.SetActiveWindow is win32gui.SetActiveWindow
True

To remove pywin32's own usage of winxpgui in code, I had to touch the ietoolbar demo, which I had to fix to test.

As for Internet Explorer, technically there's a mode in Edge to allow
some sites to run pages in "IE mode" (that thing really won't die,
will it?), but that's still through the Edge application.
The iebutton and ietoolbar demos technically do install an addon that
I can see and enable in "Internet Settings", but idk if they can
really do anything (and as such, if the demos are still valid).

In that case I see no reason to not consider them valid.

I could remove it now, or leave it for a follow-up PR to keep this well-contained

[Avasam]

Seems to be working perfectly fine for me:

>>> import win32gui
>>> gdi = win32gui.CreateRectRgnIndirect((0,0,1000,1000))
>>> window = win32gui.GetForegroundWindow()
>>> win32gui.SetWindowRgn(window, gdi, True)
>>> win32gui.GetWindowRgnBox(window)
[2, (0, 0, 1000, 1000)]

(even avoiding winxpgui to prove that it's working in this new build)

[mhammond]

I like this, but my main concern is users who upgrade without uninstalling - depending on the PYTHONPATH order, there seems a good chance upgrading users might still find themselves loading the old winxpguidmodule.pyd. I'm not in a position to test that currently - are you able to?

[Avasam]

If both the old .pyd and .py are found in the same repository, it is indeed likely importing the .pyd will take precedence.

Is that an issue? Most symbols were the exact same, built from win32gui. I guess we'd want to avoid a fresh install / full re-install from possibly causing some behavior change.
I'm not totally certain how to best handle that. I could "compile" the .py file with Cython or mypyc. to ensure it overrides the old winxpgui.pyd. Should still be faster and simpler.

Edit: or learn to do the exact same re-exports I'm doing, but in C (could maybe shortcut it using cythonize) and build the very simple module.

[mhammond]

Is that an issue?

Hrm, maybe not. I guess a risk is that later pywintypes.dll ends up changing symbols, meaning an old winxpgui fails to load. OTOH though, that seems an edge case so maybe it's fine.

[mhammond]

Ok, let's YOLO this given the benefit of killing this code is real and that risk I mentioned above is both theoretical and temporary

[Avasam]

If you're good with it, I'm good with it. It removes so much complexity and speeds up build times.