{vis}[intel/2015b] Gtkmm 2.24.4 (REVIEW)

Update all libreadline easyconfig to link to ncurses

Add Advisor-2016_update2 easyconfig

added libXtst easyconfigs

reorder sources in ALADIN easyconfigs because of changed patch file

{bio} [goolf/1.4.10] STAR-2.5a (Review) 

{tools}[GNU/4.9.3-2.25] zsh 5.1.1 (REVIEW)

{system}[*/2015b] OpenSSL 1.0.1q (REVIEW)

{geo}[intel/2015b] ALADIN 36t1_op2bf1 (REVIEW)

Add tbb-4.4.2.152.eb (Intel Parallel Studio 2016)

{lang}[intel/2015b] Python 2.7.11 (REVIEW)

{numlib} [intel-2015b] CGAL 4.7 (REVIEW)

{lang}[intel/2015b] flex 2.6.0 (REVIEW)

{data}[intel/2015b] netCDF-Fortran 4.4.2 (REVIEW)

The full explanation for this can be found in issue #1315.

libreadline needs some terminal info. It can get this from libtermcap or
ncurses, which are (as far as I understand it) API but not ABI
compatible. On most (=all the ones I looked at) systems, libtermcap just
gives a redirect to libtinfo. This libraries is created by splitting a
part of the main ncurses library because most program only need this and
not full ncurses. In EB we don't do this and it's one big fat library.
Also, libreadline and ncurses don't mix. It's next to impossible to use
both of them in the same code.

The idea is that, the code that uses libreadline can choose which
termcap library to use, either libtermcap or ncurses. But as said
before, on most distro's the leads to the same library.

So, my proposed solution is: we explicitly link libreadline to ncurses.
This will definitely solve the problem in this PR but I'm not entirely
sure about potential fallout. It seems like most EB stuff already links
to ncurses when using libreadline. I'm still guessing about why this
issue does not pop up in RHEL (and derivates) but on Debian we do hit
it.

Relevant bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=499837

{math} [foss-2015a] graph-tool (REVIEW)