Improve the threshold tests

Let's use a pseudo-random image (with fixed seed) rather than a
linear gradient, since the gradients do not differentiate well
across the various thresholding algorithms.

With a 10x10 randomly generated image using seed 0xdeadbeef, I'm
happy to note that every auto-thresholding algorithm produces a
different threshold!
Add net.imagej.measure and net.imagej.operator

These packages are migrating from imagej-common. They make heavy use of
the old imglib2-ops, and are in need of update to the new ImageJ OPS
paradigm, and are hence deprecated, but continue to be available here.

See also:
https://github.com/imagej/imagej-common/commit/e8bfb41a80f355a7ef0c1dbffb67d4f991b5b925
Migrate net.imagej.threshold from imagej-common

The eventual goal is to reconcile these threshold methods
with those of ImageJ OPS (net.imagej.ops.threshold).
Organize imports
POM: add missing developer ids
AbstractThresholdTest: simplify Img creation

We can use the handy ArrayImgs utility method.
Update to the ImgLib2 2.0.2 release

This bumps pom-imagej to the latest version (3.2),
and furthermore, updates imglib2 to version 2.0.2.

It makes the necessary code changes to adjust for the
backwards incompatibilities of the ImgLib2 release.
ApplyConstantThreshold: avoid parallel map for now

As discussed in this thread:
http://imagej.net/pipermail/imagej-devel/2014-October/002281.html

The new BitType is not thread-safe when two cursors attempt to modify
different pixels residing in the same index of the backing LongArray.

Until that is fixed somehow, we should avoid using multithreaded code
to apply a threshold into a BitType image.

This change fixes an intermittent failure of ApplyManualThresholdTest.
Merge branch 'imglib2-release'

This updates ImageJ OPS to use the ImgLib2 2.0.2 release version.

It makes necessary changes to the code to address backwards
incompatibilities from previous versions of ImgLib2.
Bump to next development cycle

Signed-off-by: Jenkins <jenkins@imagej.net>
Mention the right ImgView class to use
ImgView: fix javadoc warnings
POM: bump to pom-imagej 3.3

It seems the 3.2 release was flawed somehow... and this
lets us eliminate the hardcoded version properties anyway.
POM: bump to pom-imagej 5.0

This purges any tainted references to the
not-quite-successfully-released pom-imagej 3.2.
Bump to next development cycle

Signed-off-by: Jenkins <jenkins@imagej.net>
Add JTransform as dependency
Add fft and ifft interfaces
Add Abstract(I)FftIterable
Add Abstract(I)FftImage
Add Smooth Number Utility

A class to determine the next smooth number.  This is required so that
we can find the fast fft sizes.  Research and implemention performed by
Johannes Schindelin.