Towards solving the gordian knot of dirty rectangles in GUIGraphics

In `IWindowListener`, the following functions are guaranteed to be called non-concurrently:
- `onDraw`
- `onResized`
- `recomputeDirtyAreas`
- `getDirtyRectangle`

`getDirtyRectangle` semantics is that once you have pulled the dirtyRectangle, you commit to have it mark as dirty to the OS, and consequent `onDraw` ensues with the proper WM_PAINT / dirtied area.

Try to see if there is potential conflict with:
`getDirtyRectangle` then `onResized` then `onResized`
since it may lead to the pending rect being abandoned.

Start with the IWindowListener contract and the GUIGraphics handling of getDirtyRectangle, onResized, onDraw, recomputeDirtyAreas, and the pending dirty rectangle. Reproduce or reason through getDirtyRectangle followed by two onResized calls, then define behavior that prevents a pending rectangle from being abandoned before the corresponding OS invalidation and onDraw.

Written by the indexing model from the issue text.