Convert gmx rdf to the C++ framework

Convert the RDF calculation tool to the new framework.  Main changed
beyond mechanical conversion:
 - Remove -com and -rdf options in favor of using selections directly.
   Both functionality, and a lot more, is now directly supported with
   proper selections.
 - Remove -hq and -fade options, as both are just post-processing that
   can be trivially done based on the output xvg file alone.
 - Normalization is reworked to work with dynamic selections.
 - Add an -rmax parameter that allows specifying an upper cutoff for the
   RDF.  Combined with the use of the neighborhood search routines, this
   potentially makes the tool a lot faster if the RDF is not required up
   to half the box length.

Add basic unit/regression tests for a simple water box.  The reference
values are not verified in any way, so they mainly catch regression
bugs.

Change-Id: Ieed19fc39a84e299291232190333652ced26abee
Add StringFormatter and formatAndJoin to stringutil

The StringFormatter functor wraps formatString so that we can write
one-liners that take a container, format its objects to strings, and
join them with a separator into one string for e.g. logging output.

Re-implemented joinString in terms of formatAndJoin, by using an
IdentitfyFormatter, thus eliminating duplication of implementation.

Added some tests for joinString also.

Applied new functionality to reporting GPU status information.

Change-Id: I424543a1ca4e214c438cc39f104f087e7e70030a
Fix latent bug in OpenMP initialization

mdrun worked fine because it only tries to call
gmx_omp_nthreads_init() once, but anybody trying to run thread-MPI
mdrun (e.g.) as a library or in tests would see a hang, because the
master rank never gets to the barrier because of the premature return.

Extracted a function, so that the return works as intended, which will
help us reason better about this code. Used quick return statements
for control flow, rather than nested conditionals, but there's no
other change to the functionality.

mdrun with OpenMP can now be called more than once. As a side effect,
even without OpenMP, the subsequent calls to mdrun now issue the
over-subscription warning - and all OpenMP runs report the OpenMP
settings.

Change-Id: Ie7019565ef9a513cf4dfb530e90452d4ef48289e
Remove heuristic group-scheme neighbour-list updates

-1 == nstlist used to trigger the use of an algorithm that did
neighbour searching only when particles had moved far enough that
there might be a need to update the list. This supported obtaining
better energy conservation with the group cut-off scheme. It has been
superseded by the Verlet cut-off scheme.

Part of #1292

Change-Id: I074790c1c5670e874b8b587a1d46e62e2edc8961
Four new quotes from around the world.

Change-Id: Ib2f597c1f0e55160365d9e074b02b7eacbb84298
Move code to prepare for GPU interface rework

This is pure renaming, so hopefully rebases work better. Two of the
header files were being explicitly removed from the set installed, but
now that these headers are no longer in legacyheaders, this issue is
resolved.

Change-Id: I5bbc89c2e52e0d92704896c48eeed5d9c00fd61a
Move GPU implementation to new interface

This prepares for OpenCL implementation by updating the existing
preprocessor-based interface for GPU functions (that has real
implementations with a GPU build and null implementations without).
Some related changes to identifier names, comments and docs.

Renamed
s/ncuda_dev/n_dev/g
s/cuda_dev/dev/g
s/nb_cuda/nb_gpu/g
s/cu_nb/nb/g
s/cu_nbv/gpu_nbv/g
s/cuda_dev_info/gmx_device_info/g
so they were more generic, for when an OpenCL implementation wants to
share the same identifiers. Related, some _gpu_ had to become
_cuda_gpu_ because it will only have a CUDA implementation, other
_cuda_gpu_ had to become just _gpu_, some _cuda_ had to become _gpu_
or _cuda_gpu_. Some CUDA became GPU.

Several CUDA header files are moved from mdlib/nbnxn_cuda to files of
more generic names in mdlib. This is not great either, but
reorganizing the whole nbnxn code into a proper module, perhaps with
submodules is not within the scope of this change.

Updated naming of some data types to be struct gmx_name_t, per
style in Redmine #1490. Used some explicit forward declarations
instead of including files to get them. Removed typedefs for
opaque pointers.

Moved gpu_timing struct from
legacyheaders/types/nbnxn_cuda_types_ext.h to timing/gpu_timing.h, and
the remaining content to mdlib/nbnxn_gpu_types.h. So we no longer
install this internal-use-only header.

The last part of init_interaction_const() in forcrec.cpp is split off,
so that the construction phase can be moved to occur before
init_nb_verlet(), so that the "constants" are known before any JIT
compilation of GPU kernels takes place. Future work will address the
question of handling JIT compilation more flexibly, or in more than
one place (e.g. when things become compile-time constants after PME
tuning).

Converted some Doxygen style to new guidelines, added basic file-level
documentation, updated include guards.

Introduced gpu_set_host_malloc_and_free so the implementation-specific
details can be handled in the implementations.

Change-Id: I888722c92daeccc7f32987d9b6cb15544351b68d
Implement OpenCL support

StreamComputing (http://www.streamcomputing.eu) has implemented the
short-ranged non-bonded interaction accleration features previously
accelerated with CUDA using OpenCL 1.1. Supported devices include
GCN-based AMD GPUs and NVIDIA GPUs.

Compilation requires an OpenCL SDK installed. This is included in
the CUDA SDK in that case.

The overall project is not complete, but Gromacs runs correctly on
supported devices. It only runs fast on AMD devices, because of a
limitation in the Nvidia driver. A list of known TODO items can be
found in docs/OpenCLTODOList.txt. Only devices with a warp/wavefront
size that is a multiple of 32 are compatible with the implementation.

Known issues include that tabulated Ewald kernels do not work (but the
analytical kernels are on by default, as with CUDA), and the blocking
behaviour of clEnqueue in Nvidia drivers means no overlap of CPU and
GPU computation occurs.

There is some duplication between the two GPU implementations, but
the active development expected for both of them suggests it is
not worthwhile consolidating the implementations more closely.

Change-Id: Ideaf16929028eb60e785feb8298c08e917394d0f
opencl-for-gerrit
Merge branch 'mabraham-opencl-for-gerrit' into opencl-for-gerrit