gdiplus: add a drawing test for GdipFillRectangleI

[Vincent Povirk]

> As for me I'm not against it if it'll work stably, but will this really
> help? It's much easier to check this visually, comparing with native output.
I think it will help. It should be stable as long as we are careful
about how strict the tests are. It's probably not as appropriate to be
this strict most of the time.

In this particular test, I think we can expect pixel-accuracy. By
default there is no antialiasing, and the shape is a rectangle.
Similarly, if we draw a raster image at integer coordinates, we should
get a consistent result.

Checking things visually is not easy for me. It requires me to write a
test program or find an existing program that uses a particular call
in the way I want, and I don't trust myself to do the test without
mistakes. It does not fill me with confidence that anything in our
current implementation is correct. When I'm looking at a bug that
could be caused by any of a number of functions (because I'm not sure
of the correct behavior), tests help.

> These pixel-by-pixel tests should use current bpp depth for 'relaxation'
> when we start draw gradients for example...That's will add another
> complexity.
I'm not sure what you mean.

The current bpp depth shouldn't be an issue if I've done this right.
It should do 32-bit tests regardless of the display.

> Maybe it makes sense to add an antialiasing drawing tests to find out a
> closer algorithm for line drawing with different SmoothingModes...
I'm still stuck on the question of how we can implement antialiasing
while relying so heavily on gdi32.

Vincent Povirk