111 contrib FFTW v2.1.5

In paper mentioned by https://github.com/hpcugent/easybuild-easyblocks/issues/111 you may notice that multiple versions of FFTW are popular among HPC applications, at scale.

Ref. http://www.fftw.org/, v2.1.5 and v3.x APIs are not compatible; it follows that,
it is practically required to include both FFTW variations for most HPC sites,
perhaps along with some --float variations, as evidenced by builds like:
https://github.com/fgeorgatos/easybuild.experimental/blob/master/users/fgeorgatos/GT/n/NAMD/NAMD-2.9-goalf-1.1.0.eb
https://github.com/fgeorgatos/easybuild.experimental/blob/master/users/fgeorgatos/GT/g/GROMACS/GROMACS-4.5.5-goalf-1.1.0-FLOAT.eb

ps. 
if you can come forward with a naming standard as regards the namespace for such parameterization, this is a really good moment to drop in the discussion...
The altversions feature, which is not yet automated, could be really useful in such "parametric" builds.

ps2.
Despite FFTW is a simple algorithm in principle, there is a significant set of choices when it comes to building it. If you have experience about how it's best to reduce this space to, say, a handful of options, that's desired ASAP.

N.B. 2013-05-01:
The recent jumbo-FFTW builds make much of this PR irrelevant; the only pending work is around v2.1.5, so changed title of this issue.