gdiplus: fix GdipFillRectangleI no effect on memoryDCwhosewindoworigin point has changed

[Vincent Povirk]

Thank you for continuing to work on this.

It is possible for graphics->hdc to not be NULL when graphics->image
is a Bitmap object. You can see in GdipCreateBitmapFromScan0 that we
create an HBITMAP object for some pixel formats, and
GdipGetImageGraphicsContext will create an HDC if an HBITMAP exists.
This is currently necessary because our non-gdi32 drawing code is
incomplete, but when that is fixed we will no longer create HBITMAP or
HDC objects for Bitmap objects.

We should still leave alpha_blend_pixels_hrgn alone because we control
these HDC objects and will never change their window origin.

Your approach looks good, but I have some issues with the tests.

I would prefer that you use the expect() macro when comparing integers in tests.

If you don't expect a function (in this case GetDIBits, in patch 2) to
fail when running a test, use ok() to check that it succeeded. It's OK
if the test will crash when the ok() check fails.

If GetDIBits really does fail sometimes, we need to understand why
that happens and document it in the test.

When writing comments about this, make sure you specify that you are
talking about gdi32 device coordinates, which are different from
gdiplus device coordinates.

+    status = GdipSetClipRectI(graphics, rect.left+width/2, rect.top+height/2,
+            rect.right, rect.bottom, CombineModeReplace);

This looks wrong to me. GdipSetClipRectI takes a width and height, not
right and bottom.