Add canvas width/height modifiers to pdLayer

These will be used to provide real-time on-canvas non-destructive
resizing of individual layers.
Add tool-specific chunk to the canvas render pipeline

Now that we are ready to start working on various on-canvas tools, we'll
need to set aside part of the render pipeline for tool-specific
rendering.

The first tool to be tested against the new pipeline is a "transform"
tool for individual layers, which basically allows the user to
non-destructively resize layers directly on the canvas.  This is a big
improvement over most layer scaling tools, which only provide
destructive (permanent) scaling.

Note that this change affects how selections work.  Previously,
selections always displayed transform nodes, regardless of the active
tool.  Now, they will only display transform nodes if a selection tool
is actually active.  (But the selection itself will *always* be
displayed.)
Update FreeImage to latest dev build
Add new FreeImageResizeDIB function to mimic the GDI+ version

This will allow me to profile each, which will be very helpful during
the upcoming render pipeline modifications.
New viewport-specific layer compositor

Warning: large commit!

There are two ways to get a composite copy of a layered image, when the
goal is to view the composited image on-screen (e.g. in the main
viewport).

1) The easy way: composite the image at full-size, then shrink the whole
thing to viewport size.  This is what PD has done so far.  The problem?
Compositing everything at full size is a waste of resources if the
viewport is smaller than the image itself, and heavy actions (like
custom layer blend modes) are made more egregious by blending the layers
at full-size.

2) The hard way: iterate through each layer, extracting only the parts
that will be visible in the viewport.  Shrink those layer sections to
their viewport size, then do any special compositing on the shrunk
portion (blend modes, etc).  Advantage: only the relevant on-screen
portions of each layer will be processed, saving valuable time.  Also,
when zoomed-out, far less pixels will be processed than a full-size
composite, because each layer is shrunk *before* blend modes are
applied.  Disadvantage: much more difficult to code.  Also, multiple
resizes are needed (one per each layer chunk), though this is offset by
only resizing the absolute minimum number of pixels per layer.

At any rate, I have completed work on the second viewport option, which
is a BFD for PD's rendering pipeline.  (In fact, I have held off on
implementing blend modes until this was ready.)  I have also done the
hard work of optimization up-front, so the routine is very smart about
what it processes - for example, layers that lie off the viewport are
ignored, and layers partially on the viewport only have their
on-viewport sections processed.

The biggest slowdown in this system is, as expected, GDI+ resizing.  The
net viewport render speed is roughly identical between methods 1 and 2,
with method 1 struggling to resize a full-sized image down to viewport
size, and method 2 having easier resizes, but also more of them.  The
real speed difference between the two methods will manifest when blend
modes are implemented, however, as the advantages of method 2 will be
huge (as all blending will be per-pixel VB6 code).

The pdImage class is becoming a bit bloated on account of all this new
compositing code, so I may look at moving composite code into a
dedicated class.