Added some timing functions, changed a little code

Added timing functions to see where the time is actually being spent.
Obviously, the median filter is taking the brunt of the time, but it
gets way slower at larger image sizes than I expected.  I guess because
it's running on every pixel (with no roll over), time is dependent on
the square of the radius of the filtered area. But even so, the time for
an image with radius 500 was 17.3 s, whereas the time for an image with
radius 1280 was ~200s, which is a factor of 10 increase, but only a 2.56x
increase in radius...

It seems like something is still acting funny, but I'm not sure where it
would be.  The next steps seem to be utilizing the "verbose" parameter
correctly, and working to make the serial version faster before looking
into parallel options (openCL? any idea how to do GPU code?) - figure out
exactly how oversampling affects the median, so that I can make a rolling
filter and implement it soon.

Also, instead of dealing with edge cases in the actual filter functions,
I should look into just creating an image with the edge overlaps incorporated,
then just run the filter on the inner part of the image.  That will leave
the filter functions general, as well as cause less checks to be performed
during the actual filtering (which may speed it up a little bit?)