set int33 event status bit 8 when passing absolute mouse coordinates

[javispedro]

This is a small extension to the int33 API provided by the mouse.cpp int33 driver.
It sets bit 8 of the event status word (currently unused, last previous used bit is 7 for the cutemouse wheel extension) whenever DOSBox is passing absolute mouse coordinates to the user program. That is , when the mouse is not locked.

The goal of this extension is to allow the int33 program to determine whether it should prefer to use the absolute coordinates (if the bit is set), or whether it may use the relative coordinates in mickeys (if the bit is unset). It is only useful in emulation/virtualization environments where the mouse may be integrated with the host cursor. When it is integrated, the guest program may decide to utilize only the absolute coordinates in order to appear seamless. When it is not integrated, the guest program can instead fall back to the relative coordinates and compute speed, acceleration, sensitivity, etc. in the way preferred by the program.

I am using this new bit in yet-another Windows 3.x mouse driver, except this one is using the int33 protocol rather than any VM backdoor. This allows it to be "universal" and work under most DOS mouse drivers (cutemouse), other "absolute" mouse drivers (like my VBMOUSE.EXE DOS driver, which is for integration with VirtualBox/VMware), as well as other DOS emulation environments.
For example, it works under dosemu2 - this patch is already applied there , here you can see some discussion about the changes.

The only change required in DOSBox-X for this driver to work is this PR. The new bit 8 is used to decide whether to set the SF_ABSOLUTE bit in Windows (when using mouse integration) or not (in which case we use relative information and the mouse speed settings in Control Panel work).

This 3.x driver, in addition to using mostly standard int33 interface, has some nifty additions like slightly improved wheel support (using the Cutemouse API), discussed here NattyNarwhal/vmwmouse#5 (comment)

The wheel part works as-is in latest DOSBox-X (with Cutemouse wheel API) already:
https://user-images.githubusercontent.com/123961/163279165-51e20586-6225-4fb4-a002-35de11cca853.mp4

If you want to find the latest binary of my win3.x driver, see https://git.javispedro.com/cgit/vbados.git/about/ , including installation instructions at https://git.javispedro.com/cgit/vbados.git/about/#windows-3x-driver

The DOS mouse driver is likely not useful for DOSBox-X (albeit it does work).

Note: there is a problem under DOSBox-X when using DOSBox's int33 driver under Windows (with or without this driver). The problem is that the moment you open a DOS program from within protected mode Windows, the DOS program will reset the int33 driver and therefore disconfigure the driver for when another DOS app (or Windows itself) gets back to it. On real hardware, Windows has some support for "instancing" the int33 driver (i.e. create one copy of the driver for each DOS window) so that they don't interfere with each other nor with Windows iself. But it cannot "instance" the DOSBox int33 driver, since it is outside the emulation.
You can see this problem in DOSBox-X if you open multiple DOS programs under Windows (each of them using the mouse). They will interfere with each other and eventually crash (because at some point DOSBox's int33 driver will try to call the event handler of one application while the other one is running).
This is not related to this PR.