The current implementation of complex and rectangular clipping in the
reference 2D port is sub-optimal in a few ways.

- Information is kept in redundant formats and locations.  For a
simple rectangular clip, the same information is kept in a Shape object,
a Rectangle object and 4 integer fields in the Graphics object which
store it in a more useful UpperLeft/LowerRight format.  For a
complex region, the bounds of the non-rectangular clip is also kept in
the Rectangle object and the 4 integer fields.  This wastes space.

- The preferred location of the information depends on the state
of the Graphics object.  If it is rectangular then the redundant extent
fields store all of the information about the clip.  If the clip is
non-rectangular, then an optional "Region" object must be consulted.
Multiple locations to retrieve clip information make it difficult to
write single pipelines that handle both rectangular and non-rectangular
clipping.

- None of the low level graphics primitives, or any of the platform
graphics pipelines handle complex clipping.  Some of this is due to
lack of engineering resources to add this capability and some of this
is due to the complexities listed above making this task more difficult
than it needs to be.

- Much of the manipulation of rectangular coordinates of the form
x,y,width,height is not properly checked for overflow which could
lead to undesired results (it should be pretty safe since the final
clipping is all done in an overflow-resistant UpperLeft/LowerRight
format, but we could end up calculating the wrong UL/LR values from
the XYWH values.