Move custom modulo code to a single public function in the Math module
Convert custom rotate code to a standalone function...

...that operates on a source and destination layer.  This is required
for the forthcoming motion blur, which requires access to the newest
custom rotate function.

Also, this commit includes a rather odd function that grows a layer and
clamps all new borders to the value of the nearest valid pixel.  This is
required for certain functions (again, forthcoming motion blur) that
require access to off-image pixels.  Rather than write complicated
edge-handling code, it's easier to just up-size the image, perform the
function, then downsize to original dimensions.
Improve comments (and menu icon) for radial blur
New motion blur tool (aka, "VB6 kicks ass")

Warning: somewhat off-topic commentary incoming!

I've been pondering a new blog article for some time, basically along
the lines of "why VB6 is still a valid development tool".  At the top of
the list would be VB6's native code performance, and this new motion
blur tool is a perfect example of how impressive the original VB6
compiler is (despite being some 15 years old).

First off, let me state that with the exception of PhotoDemon's Gaussian
blur function, which was a special case, I'm not much of a code
optimizer.  My coding goal is cleanliness and readability, and while I
like to do very basic optimizations (look-up tables, etc), I'm pretty
lazy when it comes to PD's performance.

For this new motion blur tool, I followed the basic pattern I do with
most new tools: search the web for "motion blur algorithm", peruse
whatever I find, including the source of other open-source photo
editors, then throw together a prototype that favors whatever code
routines I have on hand.  In the case of motion blur, I basically
re-used my existing pure-VB rotate function, a pure-VB horizontal blur,
then the same pure-VB rotate function to return the image to its
original orientation.  There are a few extra steps in there, but that's
the gist of it - not particularly efficient, but easy for me to throw
together during a bit of spare time.

After a first draft of a new tool, I like to pit it against comparable
tools in other photo editors, most commonly GIMP and Paint.NET.  I
choose these two because they are free, actively developed, well-known
photo editors with solid development histories.  GIMP is written in C
and Paint.NET is a poster-child for .NET (written almost entirely in
C#), so these are two different and very helpful test cases for
comparing PhotoDemon's baseline performance.

My typical test image is an 8mp JPEG taken from an iPhone 4, or what I
consider to be a "very average photo".  Using that photo, here are my
results for a motion blur at 235 degrees and a very overkill distance of
200 px (on my 5-year-old core i5 w/8gb ram, of which PD/VB6 can only
access 2gb):

PhotoDemon: 17.5 seconds (including Processor module parsing, painting
to screen, etc)
Paint.NET: 2 minutes, 5 seconds (@ quality 2/5)
GIMP: 41 seconds

Just to demonstrate that I'm not picking on a deliberately advantageous
tool, here's similar results for PD's new radial blur tool @ angle 180,
same photo:

PhotoDemon: 9.2 seconds
Paint.NET: 34 seconds
GIMP: 4 minutes, 45 seconds (yes, you read that right - nearly five
ridiculous minutes)

Even more shocking with radial blur is that PD's final image looks *much
better* than both GIMP's and Paint.NET's!  And let's not forget that PD
does this while using roughly 1/4 the memory of either program.
(Checked after completion, private working set memory via task manager:
PD 33.6mb, Paint.NET 120mb, GIMP 171mb)

I wanted to jot down these numbers while I had them because I can't be
the only one who finds them shocking.  When a photo editing tool thrown
together in an hour using a 15-year-old compiler is beating established
tools in C and C# by an *entire order of magnitude*, something is
clearly amiss.  I don't want to blame the GIMP or Paint.NET devs,
because I'm sure they are competent people - their software demonstrates
that - but really?  How is this even possible?

(That said, I do call bullshit on this bullet point from Paint.NET's
"features" page: "Extensive work has gone into making Paint.NET the
fastest image editor available. Whether you have a netbook with a
power-conscious Atom CPU, or a Dual Intel Xeon workstation with 8
blazingly fast processing cores, you can expect Paint.NET to start up
quickly and be responsive to every mouse click."   LOL)

What makes this even more shocking is that things like radial and motion
blur are very easily parallelized.  I know parallelization is hard to
implement, but graphics operations like these are the absolute simplest
tasks for taking advantage of SIMD, hardware acceleration,
multithreading, or just about any other parallelization technique.  My
code is pure VB using basic 2D arrays and geometry - and when the VB6
compiler came out, SIMD extensions were limited to some very basic MMX
stuff (which the VB compiler doesn't even use!).

I really don't know what to make of this, except that I have a fun
bullet point for my next PD release announcement... :/   Mostly I'm
saddened that modern development tools (or possibly modern code
techniques) are so horrifically inefficient.

Note to self: when I do finally write this article, I should get others
to test these same functions, just to make sure my PC isn't some voodoo
machine that secretly favors VB6...