pdCompositor: fix coordinate math when non-destructive FX are active

Because we have to manually apply non-destructive effects using
per-pixel code, the compositor goes to great lengths to ensure that only
the smallest possible rect is generated.  Unfortunately, this means some
messy math to make sure that the data aligns properly when it is finally
rendered to the screen.
pdCompositor: countless optimizations

Okay, maybe "countless" is hyperbole, but still, there are about a dozen
crucial performance updates in this commit, plus a few more bug-fixes.

- Temporary DIBs required for non-destructive FX and non-standard
blendmodes are now cached at module level.  This saves us having to
recreate them, if an image only has one non-standard layer.  (e.g. a
single-layer photo, with non-destructive FX active).  Unfortunately,
multiple non-standard layers inevitable require multiple temporary DIBs.

- The temporary layer used for compositing is now cached at
module-level.  New checks are in-place to only recreate this when the
total viewport size changes.

- Previous BitBlt and StretchBlt optimizations have been restored for
relevant conditions.

- DIBs can now be cleared via a new "ResetDIB" option.  This uses
RtlFillMemory to wipe the DIB's data section, which is significantly
faster than previous image-specific GDI and GDI+ fill wrappers.

- When a pdImage is deactivated, its compositor is now preemptively
cleared too.  This should free up a (trivial) amount of memory.

- Some additional coordinate calculation bugs were fixed.  Layers should
now be rendered to identical sub-pixel coordinates regardless of blend
mode or non-destructive FX state.
Use subpixel positioning for layer tool corner nodes

They now look much prettier, particularly when zoomed-out.

Layer boundary lines (if enabled) have not been updated, and I probably
won't get around to it any time soon.  GDI+ does not have an invert
mode, so we'd need to draw the lines manually, and that's a pain in the
ass.  GDI doesn't support floating-point coordinates, so yeah... it is
what it is.