Windows pen handling invokes undefined behaviour

[Susko3]

• Regressed with pen: Windows pen support. #11826

SDL pen handling on Windows will selectively handle some (pen) pointer events while ignoring the rest and passing it to DefWindowProc.

SDL/src/video/windows/SDL_windowsevents.c

Lines 1145 to 1146 in a4cd17c

	} else if (pointer_type != PT_PEN) {
	break; // we only care about pens here.

Microsoft docs explicitly call this out as undefined behaviour:

If an application selectively consumes some pointer input and passes the rest to DefWindowProc, the resulting behavior is undefined.

The wording is unclear. Perhaps this is trying to tell that all message types (e.g. WM_POINTERDOWN, WM_POINTERCAPTURECHANGED, etc.) for a given pointer type (PT_*) should be handled.
But even if you take this lenient definition, SDL may still violates it as it ignores pens it "doesn't already know about" and doesn't handle all pointer message types.

The side effects of not following the documentation might include (completely untested, just educated guesses):

• touch input not working properly (PT_TOUCH)
• windows precision touchpad input not working properly (PT_TOUCHPAD)
• mouse input not working properly if EnableMouseInPointer is used (PT_MOUSE)
• unhandled pen-related pointer events causing general weirdness and incoherent behaviour

[icculus]

Moving this out of the 3.2.0 milestone until (and if) more bug reports show up. See discussion in #11869.