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.

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, 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

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.

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.

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.

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.

The contents of the files containing git settings is evaluated by the shell, which can
be dangerous if such a file contains a line like 'option value; rm -rf /'. While that is
unlikely, it might happen when people try to create a Git alias.

It would be possible to completely protect users from this problem by parsing the line
completely manually (without involving the shell), but on the other hand, being able to
use shell features for determining option values seems like a good thing to have as well.

This patch adds some rudimentary protection that protects against errors like the one shown
above. More advanced users can still wreak havoc by abusing shell substitution
('option $(echo value; rm -rf /)' comes to mind), but that's not something our average user
will do.

The protection works by splitting the input line into an array first; doing so does not
actually execute the line and so prevents anything outside of value substitutions in $()
from being executed.

Also added a comment to explain why we need to go through the extra step with the array.

As Carsten correctly pointed out, it's easier to just eval the command directly.