[Region Refactoring] Move region data into its own struct

[hughbe]

GDI+ internally actually stores regions as the following:

typedef enum {
    NodeTypeAnd = CombineModeIntersect,
    NodeTypeOr = CombineModeUnion,
    NodeTypeXor = CombineModeXor,
    NodeTypeExclude = CombineModeExclude,
    NodeTypeComplement = CombineModeComplement,
    NodeTypeRect = 0x10000000,
    NodeTypePath = 0x10000001,
    NodeTypeEmpty = 0x10000002,
    NodeTypeInfinite = 0x10000003,
    NodeTypeNotValid = 0xFFFFFFFF,
} RegionDataNodeType;

typedef struct {
    RegionDataNodeType type;

    union {
        GpRectF rect;
        struct {
            GpPath *path;
            BOOL lazy;
        };
        struct {
            int leftIndex;
            int rightIndex;
        };
    };
} RegionData;

struct GpRegion
{
    RegionData mainNode;
    RegionData *combineNodes;
    void *regionDataLazilyCreated;
}

Essentially, as a performance optimisation and for ease of implementation GDI+ actually doesn't perform any CombineMode operations when calling things like GdipCombineRegionRect/Path/Region. It just modifies the current mainNode to be a combine operation between two functions.

We need/should to copy GDI+ for several reasons

• We do not have any compatibility between GDI+ and libgdiplus is important in GdipCreateRegionRgnData and GdipGetRegionData[Size].
• If/when we start reading EmfPlus metafiles, regions are in a binary format matching the manner described above. So we need to be able to a) serialize regions to something GDI+ understands and b) read regions created by GDI+ (which we currently cannot do)
• GDI+ and libgdiplus differ in their understanding of empty/infinite regions after performing combination functions and aligning their behaviours is one way to improve compat
• Currently everytime we perform a combine function we actually execute the region steps. Instead, we should be "on demand" as GDI+ is, for perf reasons. Also, GDI+ is a lot more performant that libgdiplus in that it avoids creating a bitmap of the size of the region

This PR does not actually make any headway towards these aims but is a necessary step along the way, because I will be refactoring the code to lazily create rects or tree/path. Therefore, storing all of the data in a structure called a RegionCachedData is a good thing for now. The PR just avoids horrible diffs in the future

This will not only align us more with GDI+, but it will improve our performance AND actually improve the accuracy of our functions as we will hopefully be getting rid of the horrible bitmap stuff.

Let me know if I'm not making sense!

[hughbe]

Closing, as libgdiplus is deprecated