This was lost in the last commit.

Somehow we ended up putting CMAKE_PROJECT_SOURCE_DIR/lib into the
linker path. There should not be any library there and it should
not be needed for linking anyway. Additionally it causes warnings
in dune-grid-howto. Therefore this patch simply removes it.

The name of the file changed in one of the recent patches. This
change is now also reflected in the install directive. Fixes #1426

Previously, we used >=0.0. if there was no version information in the
dependes and suggests clause of a dune.module file. This breaks with
the new more strict version checking. Therefore with this revision no
version gets set if it does not appear in dune.module

Before we tried to search for dune-common twice (once without a version
and then with the required version). Unfortunately this breaks because
we are adding the same library target twice. With this patch we only
search for a module once.

The temporary file <dune-module>-config-version.tmp!

With this patch autotools now creates the file
<dune-module>-config-version.cmake mit autotools. To facilitate this
we added the variables DUNE_MOD_{MAJOR,MINOR,REVISION} to the makefiles.

Before this patch we always relied on dunecontrol/pkg-config to check
for the correct version. With this patch we include this functionality
also when building packges with dunecontrol for this use part of the version
checking of cmake (or pkg-config if there are packages without CMake support).
Basically we let CMake check wether the major and minor version matches and
afterwards use the information from the dune.module file. This should make
it possible to have several versions of DUNE installed and still always use
the correct version. During fixing these issues we noticed that our version
files were not recognized because the carried the wrong name. Now we use the
correct name <dune-module>-config-version.cmake.

This fixes FS#1422.

Replace tabs by spaces.

One of the latest patches prevent the macros of the current module
form being executed. This patch fixes this by including the module
in the dependency tree.

When making the entries of ALL_DEPENDENCIES unique, we skipped modules that
did not ship a Dune<ModuleName>Macros.cmake macro. This caused their libraries
to be missing in DUNE_LIBS. This patch fixes this situation.

Previously we already processed dune.module but in a much later stage during
configure. Dependencies are contained in dune.module. Therefore there is no
need to replicate them in the CMake package configuration files. With this
patch we now always process dune.module directly after finding the DUNE module.
In addition we set ${DUNE_MOD_NAME}_(DEPENDS|SUGGESTS} in the CMake environment.
As with this change DUNE_MOD_NAME will usually be set to to dune-common, we
also changed to using ProjectName and ProjectVersion (the canonical CMake names)
to refer to the current module and version.

In the CMake package configuration files generated with autotools
the CMake name of the library target contained a bogus lib in front
of it. This packages fixes this. Now the library can be referenced
in CMake as dunemodule (without dashes).

Before this patch we tried setting am_dir for directory with a
DUNE module. If one is working with local modules
(e.g. dune-common and dune-geometry), that are a subset of installed
modules (e.g. dune-common, dune-geometry, and dune-istl), that are all
installed under the same prefix, then modules that are part of the difference
of the set of installed and the set of the local modules caused am_dir to
point to the am directory of the installed dune-common directory.
After this patch  am_dir is only set once, which fixes this behaviour and
flyspray issue #1420

Fixes flyspray issue 1418, see https://dune-project.org/flyspray/index.php?do=details&task_id=1418

when we try to send data, it might happen, that for some reason we don't want to any data.
This happens, when the dynamic size of our CommPolicy is 0. In that case we must not add a
MessageInformation, otherwise we get an MPI error.

Somewhere along the many changes we stopped forcing usage of pkg-config when
testing for installed versions of modules during configure. Without using
pkg-config there is no way of detecting custom installation parts used by
the user. In my case, this broke finding modules installed via cmake from
modules that are to built with autotools.

This patch forces DUNE_CHECK_MODULE to use pkg-config to setup the paths for
installed modules by dunecontrol not provinding --with-module=<path> to configure
for installed modules.

Improve comments.

Previously we checked whether the extracted Version evaluated to
True. Unfortunately, there lazy people like me that like use a version
of 0 for testing, which evaluates to False and breaks configure.
With this patch we allow 0 to and just test wether the version consists
of characters.

A variable was not correctly escaped during creation of the file
cmake/modules/Makefile.am causing the error message:
"duneproject: line 914: datadir: command not found."

This patch now correctly escapes it.

duneproject failed miserably when run with only installed modules. With
this patch we correctly setup the pkg-config and dunecontrol path to
handle this situation. In addition we fixed various issues with the newly
created modules and they now build as exspected.

With new modules there were cases where cmake/modules was not in the
modules path which made configuration fail. This patch fixes this case.

Due to testing the wrong directories some variables where missing in the
package configuration files. This patch fixes this.

The clutter the output.  I can't believe anyone really wants to see
the friend relationships in doxygen.