The default constructor of the FieldVector has intentionally avoided calling a
constructor for the contained data to eliminate the potential overhead of that
initialization.
During implementation of a new creation mode of the BCRSMatrix, it was discovered
that this behavior is problematic due to its inconsistency: If the data type
contained in the FieldVector is a non-trivial type, a default-constructed
FieldVector will be fully initialized. On the other hand, with a primitive data
type it will be in an uninitialized state, potentially causing undefined behavior.

As this behavior might be very unintuitive for users and made implementing the new,
more efficient creation method for the BCRS matrix very difficult to implement, this
patch changes the FieldVector default constructor to always default-construct its
contents regardless of its type. While this change does introduce a possible
performance regression (for primitive types, the compiler now has to zero out the
memory), the overhead has been measured to be minimal.

The actual implementation prefers to use the new C++11 unified initialization
syntax and falls back to std::fill for older compilers. The distinction was made
because newer compilers generate much more efficient code when using unified
initialization, and for user-defined types, this approach avoids first calling the
default constructors and then the copy assignment operator.

- 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