- update documentation
- add paranoia check to touch()

update documentation

Previously, when adding boost flags, we always linked all
Boost_LIBRARIES. At least for the core modules this not needed
and resulted in errors on some systems.

This patch changes the add_dune_boost_flags function. By default no
libraries are linked, but one can either provide the libraries using
the LIBRARIES option or request linkage of all boost libraries with
the LINK_ALL_BOOST_LIBRARIES option.

Previously, if the user changed e.g. CMAKE_INSTALL_PREFIX or
CMAKE_INSTALL_DATAROOTDIR these changes where never mimiced in
DUNE_INSTALL_MODULEDIR. This patch fixes this problem, such that
DUNE_INSTALL_MODULEDIR changes unless it is explicitely set by the
user before.

We do using the same approach as in GNUInstallDirs.cmake. That is, we
whether DUNE_INSTALL_MODULEDIR is set to a non-empty string. If that
is the case we set an empty cache variable and overwrite locally with
the default value. The default value is now a relative path.

This fixes FS#1317 for me (use invert for 2x2 matrix with
std::complex< long double >).
The problem is that 1.0 is a double, which can be converted implicitly
to a long double which, in turn, could be converted implicitly into a
std::complex< long double >. However, the compiler does not use two
implicit type conversions, so double cannot be divided by a
std::complex< long double >.

See FS#1317 for details.

GNU xargs behaves differently from BSD xargs in that it always executes the command
at least once, even if there are no arguments on stdin.
As noticed by Martin, this behavior breaks the whitespace hook if the list of files to
be checked is empty. In that case, the hook will now check *all* staged changes, resulting
in false alarms.

So we test which version of xargs we have and use the correct flags in either case. If neither
one works, we bail out and ask the user to file a bug, but this behavior can be overriden with
the environment variable DUNE_WHITESPACE_IGNORE_XARGS.

Fixes FS#1316.

CMake honors the familar compiler flags if they are exported. This patch
extracts them from CONFIGURE_FLAGS and exports them to cmake by putting
them in from of the cmake call.

Some modules do test for complicated symbols,
eg. "&StandardMerge<double,1,1,1>::build;", which lead to broken
configure scripts. In the above case :
" 1>build;
  ;"
as a shell command.
This patch quotes the program body used for AC_LANG_PROGRAM correctly
to prevent this.

Previously we relied on CMake's export(PACKAGE ...) function when
finding dune packages without dune-control. This is error prone
when using several instances of a dune-module (either with differing
versions or built using different options). In this case there is no
control which of the instances is used.

Now we try to guess the correct build directory, if it was not
provided with ${module}_DIR, ${module}_Root or in the
CMAKE_PREFIX_PATH. Note that when using dunecontrol ${module}_DIR will
always be set. We take the path of the current toplevel build
directory and simply substitute any occurence of the name of current
module with name of the module that we try to find. This works for
both  building in a subdirectory of the source tree
(e.g. ${module-source}/build-cmake) or in a sibling directory
containing the module name (e.g. ${module}-build).

MPI_FOUND is already deprecated in CMake 2.8.6 - our minimal
required version.

To set variables like DUNE_COMMON_REVISION the macro dune_module_information
is called. To surpress output the macro gets an additional second
argument to QUIET the output. To set the PACKAGE_* variables correctly
dune_module_information is called a second time for the current module
after it was called all the other modules.

The test result was never used. The test slipped in as a copy from
the CMake code snippet from DuMuX.

Make sure to always quote paths that are relative to PREFIX_DIR, as that variable
may contain spaces.

Some Dune users like to aggregate all the Dune modules required for a project by
creating a Git repository with a Git submodule for every submodule. Unfortunately,
dunecontrol currently doesn't recognize the submodule repositories currently because
Git aggregates all repositories in the .git directory of the superproject (more
preciselyin in the subdirectory .git/modules/). In the submodule, .git is a regular
file that contains a referral to the actual repository directory.

This patch fixes the problem by

- Detecting Git directories by looking for both directories and regular files called
  .git in the module directory.

- Following the referral in submodules for the hook setup to make sure the hook gets
  installed in the correct location.

Fixes FS#1303.

Conflicts:
	.gitignore

quick-fix to make CMAKE builds respect the DUNE_BUILDDIR entry in opts
files

This is the same fix as for debugallocator. See flyspray #1287.
The problem was that move semantics were used if the compiler supports
variadic templates.