DirectDraw acceleration still does not work properly with MS DirectDraw stack

This ticket is a continuation of an old CORE-7733.

To reproduce the issue:

1. Replace ddraw.dll and dxg.sys by the ones from Windows XP/2003. Optionally the following components can also be replaced: dciman32.dll, ddrawex.dll, dxapi.sys, dxgthk.sys. But replacing them also is not necessary at all.
2. Reboot the system.
3. Run ReactX Diagnostic Tool from Start Menu.
4. Try to perform DirectDraw test (although it also can be reproduced with other 3rd-party DirectDraw apps/games).

The first test will work without any issues, but the 2nd and 3rd tests will fail (the white square will not be displayed on the screen). It proves that the DirectDraw acceleration support is not implemented properly in our Win32 subsystem.

When I tested a checked builds of MS ddraw.dll and dxg.sys, there also appeared an additional debug output from them, which shows the problem:

(/win32ss/reactx/ntddraw/ddraw.c:577) Calling dxg.sys pfnDdGetDC

DXG: dxdiag.exe or DLL gave bad handle 0x00000000 as an hddrawsurf.

DXG: DxDdGetDC: Couldn't lock the surface

Direct3D9: (ERROR) :Could not obtain DC

This is displayed many times, because MS ddraw.dll tries to call it again and again, and each call is not successful. See full ddraw-debug.log for details.

The actual source of problem is invalid surface handle passed from DirectDraw to win32k. This is happening because the parameters in the appropriate call of Win32SS function of our GDI32 are specified in the wrong ordering: 1st is a pointer to the palette entry, and only 2nd is a handle to surface. It should be 1st instead. Then it's passing to win32k successfully.

How it works:

1. First, MS ddraw.dll calls DdGetDC function in our gdi32.dll with some specified hSurface (that seems to be not NULL).
2. Then, DdGetDC in our gdi32 calls NtGdiDdGetDC callback in our win32k.sys, which, in it's turn, calls appropriate function in MS dxg.sys.

But since the parameters ordering specified in NtGdiDdGetDC is wrong, hSurface given from DDraw is passed into a wrong parameter in win32k from gdi32, so it became NULL, and then execution stops at this point.

I already made a fix for this, and after applying it, this problem is not reproducible for me anymore.

Although it's only the 1st barrier on the way to the proper support of the DirectDraw/Direct3D hardware acceleration in our win32k. After fixing it, I found another bugs those are still causing a problems in the work of MS ddraw.dll + dxg.sys.
I also implemented some other callbacks in our REACTX subsystem, whose also improve the situation, but still don't completely fix the main problem.

I'll submit some PRs with my improvements soon. Give me some time.

P. S.: The point of such replacement is, it might work better (and perhaps allow GPU acceleration) on real hardware (in the future perspective).

P. P. S.: Tested with 0.4.15-dev-2359-g0dedb9b.