[d3d9] Update software cursor position using SetCursorPosition

[WinterSnowfall]

Fixes #3020 on Windows as well.

Games relying on software cursors apparently also call SetCursorPosition on each frame, and since we call ::SetCursorPos(X, Y) when that happens, on native Windows that tends to cause some strange movement feedback for some reason when we later retrieve the cursor position before present, using ::GetCursorPos(). And, you guessed it, this works just fine in Wine...

Regardless, what seems to work just as fine both on Windows and Wine is simply using the coordinates passed by the application with SetCursorPosition calls instead of us getting the position of the win32 cursor before present.

The downside is that if any game expects software cursors to work without it calling SetCursorPosition on each frame, it will be very very disappointed now.

Needs a bit more testing to confirm the above doesn't happen in practice. For now it has been confirmed to work on Windows and Linux with Dungeon Siege 2 at least.

[WinterSnowfall]

An operating system cursor is created and used under either of these conditions:

a) The hardware has set D3DCURSORCAPS_COLOR (see D3DCURSORCAPS), and the cursor size is 32x32 (which is the cursor size in the operating system).
b) The application is running in windowed mode.

Otherwise, DirectX uses an emulated cursor. An application uses IDirect3DDevice9::SetCursorPosition to move an emulated cursor to follow mouse movement.

D3D9 docs appear to suggest this is indeed the expected approach for emulated/software cursors, so I think we should be good here. All known games using the path still work in Wine, @Blisto91 will graciously confirm it's all fine on Windows as well (hopefully).

[Blisto91]

Dungeon Siege 2, Act of War and Castle Strike seem fine on Windows with this.