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.

Previously some of the pathes (e.g the multiarch ones) took precedence
over the others. But as with same some of the pkgconfig files are installed
below lib/<multiarch> and others (if there is not object library) are not.
With this patch all possible install locations of pkgconfig files are added
to the path if they exist.

The compiler might exit with nonzero exit code if given non-existent
options. Therefore we need to use set +e during this to make dunecontrol
to continue running even the options are not supported.

Some ^[$BLANK] or [^[$BLANK]^'], where $BLANK is space followed by tab
did not work as a capturing statement in some cases (e.g. opts files
with CONFIGURE_FLAGS="CXX='bla'"). After this patch we use [$NOBLANK]
with NOBLANK=^$space^$tab which works. In addition the other patches
form feature/posix-sed-dunecontrol have been backported to close flyspray
1401.

Unfortunately gcc-4.4 does not support --print-multiarch.
Therefore we fallback to cc -v and grep for the target in this case.

Debian uses multiarch-triplets (e.g. i386-gnu-linux) when installing
object libraries. These are installed to lib/$multiarch-triplet and not
to lib directly. In CMake this concept is partially supported by
GNUInstallDirs.cmake by setting CMAKE_INSTALL_LIBDIR to
lib/$multiarch-triplet. Unfortunately, this is only half the way through
as we also install libraries that do not differ between architectures (e.g.
our shell libraries.

This patch addes multiarch support for CMake to the best of my knowledge,
which might be limited, though:

- All not architecture dependent libraries are installed below the variable
  DUNE_INSTALL_NONOBJECTLIBDIR, which defaults to lib, but might be adjusted
  by the user.
- If the module ships an object library then the pkg-config and CMake package
  configuration files are installed in lib/$multiarch-triplet/pkg-config and
  lib/$multiarch-triplet/cmake/modules, respectively.
- If not then they are installed in lib/pkg-config and
  lib/cmake/modules, respectively.

Note that for autotool no such difference exists and always the latter approach
is used.

Previously aclocal did not find the DUNE macros when they were installed to
the new location. This patch fixes this by adding the path to this list of
include paths if it is available.

Previously, the macros were installed to $(datadir)/aclocal. As we have
some macros in DUNE that are also installed for some Linux distributions
this caused conflicts in package managers. With this patch we install
them to $(datadir)/dune/aclocal to resolve this issue outlined in flyspray
task 1409
https://dune-project.org/flyspray/index.php?do=details&task_id=1409

As Ansgar not the CMake package configuration files are quite generic. This
patch autogenerates them if their templates do not exist in the source tree.
In addition duneproject and am2cmake do not generate the templates as files
in the source tree anymore.

Previously only the include path of the local modules were used. This
caused errors with installed dune-common modules, similar to:

--> aclocal...

Error: Could not find dune-common/am!
Usage: dune-autogen DUNE_MODULE_PATH_LIST [options]
  --ac=, --acversion=VERSION   use a specific VERSION of autoconf
  --am=, --amversion=VERSION   use a specific VERSION of automake
  -h,    --help                you already found this :-)
--- Failed to build dune-typetree ---
Terminating dunecontrol due to previous errors!

This is also related to https://dune-project.org/flyspray/index.php?do=details&task_id=891

With this patch we include the aclocal, m4 or am directory of all modules
(installed and local ones) and everything works again as exspected.

git-whitespace-hook is called by dune-control which barks if
it is not available. Therefore we distribute and install after
this patch.

Previously, dependencies were not correctly searched for as
required packages. This patch fixes this.

When working with installed modules, the cmake scripts and
modules of the current module should take precendence over
any installed ones. This was not the case before this patch.

Furthermore, modules downstream in the
dependency tree should be able to overwrite tests in  modules
that they depend on. This patch more caredfully crafts the
CMAKE_MODULE_PATH to reflect the module dependency in it.

With this patch the USE_CMAKE environment variable is queried whether or not CMake
should be used. This can be overwritten in an options file or on the command line
using either the --cmake or --no-cmakr switch.

Update minimal required versions to these mentioned in the documentation.
Quote argument in AC_PREREQ.
(Thanks to Bård Skaflestad for the heads-up)

Treating directories with spaces in autotools is a can of worms.
We now check whether this situation is given and issue an error when
building with autotools.

With this patch dunecontrol will work even if the path to the module
contains spaces. Unfortunately, the tests for dune modules will still
not work as I could not figure out how to use quoting in the CPP_FLAGS.

This is a follow up to the previous patch. It corrects the situation
for new modules created with duneproject.

Fix generated config.cmake.in which contained a surplus endif.
List CMakeLists.txt and other files to be included in tarballs.
Move generated files around to sort them by directory.

Previously the CMAKE variable was not set if no options file was used. This
fixes this.

With this patch it is possible to request CMake for building
by setting USE_CMAKE=yes in an option file.

In one of the latest patches I introduced a bug which caused
the --builddir option of dunecontrol to not make any effect.
This patch fixes this.

Previously a value specified on the command line was always
overwritten by a value set in an options file. This patch
fixes this together with overwriting the build directory with
the default build-cmake when --use-cmake was specified.