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.

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.

dunecontrol fails to properly process Git settings where the value contains
spaces. It was supposed to handle quoting the same way the shell does, but
instead arguments were split at each space and quotes kept verbatim in the
split arguments.

The reason is the order in which the shell performs variable substitution and
tokenizing, preventing the line with the Git configuration entry from being
tokenized by the shell.

This patch fixes the problem by first parsing the line into an array, which is
then in turn expanded again with correct per-element quoting.

In addition, make COMMENT helper variables local while we're at it.

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