Printing an image with bitmask transparency is sometimes incorrect on windows.

This was introduced in b77 when fixing :
4521945: Java 2D: RFE: improve efficiency of printing for indexed colour images

Prior to this fix a new temporary BufferedImage would always be created
which included (eg) any transformation that needed to be applied to the image
This was so the data storage for a simple rectangular area could be passed
down to native code so that it could be used (when reversed and padded) as
the data for a GDI DIB with minimal knowledge of the data storage layout.

Part of the 4521945 fix involved adding conditions under which it is
OK to directly pass a reference to the original BufferedImage's data
storage down to the native printing code instead of making a copy.

A problem exists with the bitmask transparency case as printing code
handles this as multiple smaller subimages of the original image. The
native code was however always assuming a zero offset into the data buffer.
This code needs to be able to properly navigate the Raster.

For now the simplest and least risky fix is to revert to always creating a copy.
The code that avoided the copy was rudimentary in any case, and will be revisited
at a later date. Also the scenario in which this was discovered did not actually
use the transparency. The code that detects whether we need to handle transparency
always handed off a bitmask transparent image to be printed via the mechanism which
prints as subimages without checking if in fact the transparent pixel is used in
the source image. And even when needed the code could also look to be more efficient
in using the largest possible subimage rather than a line at a time.
Resolving that is also for a later time.