fft2.FFT: restore expecting scaling behavior when calling to FFTMethods

Noticed by Stephan Preibisch:
The recent changes I introduced to the class, aimed at making it
prossible to control the number of threads used for computation,
introduced some mistakes related to the expected scaling of the results.

When using FFTMethods calls in the FFT class, the scaling must be as
following:
- calls to complexToComplex(): if forward=true then scaling=false
  if forward=false then scaling=true.
- complexToReal(): scaling is always true.
- realToComplex(): scaling is always false.

Signed-off-by: Jean-Yves Tinevez <jean-yves.tinevez@pasteur.fr>
added corresponding methods that do not require to specify the number of threads
For some reason this fails to compile on jenkins, reverting it

Revert "added corresponding methods that do not require to specify the number of threads"

This reverts commit 23c1fc20ace5e1f091f0117c1458c86d4259742b.
Revert reversion

The Jenkins failure was due to the ImageJ Nexus service being down.

I brought it back online, and all should be well now.

Revert "For some reason this fails to compile on jenkins, reverting it"

This reverts commit ce27291ce50eb888c2606916daebcfed56e329ad.
fixed missing license header in projector package
License in Volatile2DRandomAccessibleProjector fix
fixed licenses of DoubleConverters
added missing licenses
Merge pull request #47 from imglib/license-issue

Thanks @dietzc for rectifying.
change visibility of AbstractCell fields from package-private to protected.
imglib-ui doesn't depend on artifact net.imagej.ij anymore
Fix double-buffering, part 1.
fix double-buffering, part 2. double-buffering requires 3 render buffers:
The Renderer alternates between two of those.
Whenever one is ready, it is proposed to the Painter, which will,
on the next paint() call, swap it for the currently rendered image
(this is the 3rd buffer).
working VolatileUnsignedShortType
update javadoc
ShortType can be created on every NativeImg that provides a ShortAccess.
Loosen generics of NativeImg members of NativeTypes.
These restrictions are not required.
more convenient constructors for VolatileUnsignedShortType
add more VolatileNativeRealTypes, reorganize volatiles package.
The new volatile types live in the same package as the wrapped types,
respectively. This is to make the dataAccess fields of the wrapped types
visible which allows for more efficient updateContainer() implementations.
PlanarImg: make javadoc more correct

The previous text was a copy-paste from ImagePlusImg (formerly
ImagePlusContainer) and had much leftover text from that transition.