Add the initial version of the Conditions API

This package provides a general framework for ops that perform boolean
logic. The code was migrated from net.imglib2.ops.condition, and adapted
to the ImageJ OPS paradigm.
Fix compile errors in Conditions API

The AbstractCondition class now extends AbstractOutputFunction, and
knows how to create its own outputs.

One unfortunate thing in the design right now is that the output is
typed on Boolean, which is immutable. So we actually need to compute the
value of the boolean in the createOutput method, rather than in the
safeCompute method as normal.

We may want to change this design before 1.0.0, to use a boolean-style
object whose value is mutable (e.g., BitType). Otherwise, the behavior
of the Conditions API is rather unintuitive, especially if a
preallocated Boolean is passed to the op, since its value cannot change.
DefaultEquation: extend OutputFunction

The default equation op already knew how to generate its output if it
was null... but after the switch to the twin output/strict hierarchies,
it extended StrictFunction and hence could never receive a null output.
It should instead extend OutputFunction and implement the createOutput
method according to its existing logic.
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.
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