Library to pick up configuration from pkg-config files

Pkg-config files are written as part of the CMake configuration, and
these can be imported into AutoTools-driven projects to get the correct
compiler and linker options that has been probed.
Compatibility module for dunecontrol-driven clients

If a client generated with duneproject/built with dunecontrol has a
dependency to opm-material, the macros defined in this file is expected
to exist and will be called to search for the opm-material library.

All that is done here is to use the pkg-config helper module and
import the configuration that was written by the CMake system (which
even may have been called earlier in the same dunecontrol "session")
Disable link-time, whole program optimization

When using LTO, the linker calls back to the compiler to figure out
where a certain symbol is defined. However, in many versions there
is apparently a bug that is triggered if a template in inlined in
both a used library and in the main program, but with different
versions of the compiler. The Boost exception class is particular
prone for this.

Thus, we disable the -lto from the development builds by default;
if anyone wants to test of the behaviour of their own compiler, they
must now explicitly turn on this flag.
Include flag for enabling link-time optimizations

When LTO is disabled by default, we need a flag to re-enable it.
Recognize lib dirs that may be used later

This let you specify a bunch of directory names on the command line
to *all* packages, without getting annoying warnings that they are
defined but not used.
List prerequisites for modules in a separate file

This file can be included both in the project itself, and also in the
find module for the library, so that the list of dependencies can be
maintained in only one place.
Get prerequisites from a separate "header" file

Note that the variable containing the dependencies must be expanded
inside quotes; otherwise the list will spill into the argument list!
Common code for building OPM library modules

Most of the OPM libraries follow the same template; this include file
contains all the common code.
Move configure script to cmake/Scripts/ directory

We want all changes to happen there; retain a small script that
simply forwards the action to the main script in that directory.
Remove the project parameter for the customization hook

The hooks are meant to be project specific, and should therefore
either know their own name or at least have access to a variable with
that name in it.
Change marker EXCLUDE_ALL to EXCLUDE_FROM_ALL in opm_compile_satellite

Previously, when passing EXCLUDE_ALL to opm_compile_satellite this
resulted a cmake error:

CMake Error at cmake/Modules/UseDebugSymbols.cmake:71 (get_target_property):
  Cannot find source file:

    EXCLUDE_ALL

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx
Call Stack (most recent call first):
  cmake/Modules/OpmSatellites.cmake:77 (strip_debug_symbols)
  CMakeLists.txt:176 (opm_compile_satellites)
Don't include prerequisites here; do it more explicitly

Developers that are working to familiarize themselves with OPM will
probably start out in CMakeLists.txt to figure out where the project
declare its dependencies, thus the list should be referred to from
there instead of inside one of the sub-modules.
Include file list from top-level instead of module-level

Increase the visibility of the source file name include by no longer
putting it in a module, but rather by including it in CMakeLists.txt
Adjusts macro documentation to recent change.
Add function to detect linker version

The linker that is used (ld vs. gold for instance) is often hidden
when using the compiler as a front-end (to include the correct
runtime libraries).

These functions enables us to probe the linker version and reports
its finding in the log.
Print linker version to log
Parse RHEL5 linker strings better
Eliminate _MODULE_DIR variable

It is only used in one place, where it can easily be replaced by its
expansion. The reason for removing it is that it depends on the name
of the project, and I intend to read this using a routine it the very
directory it is including, hence the need for a different approach.
Read project properties from dune.module

We cannot generate dune.module because that file is read by dunecontrol
before the build starts. It therefore make sense to let it be the
original and let the build system read it instead of duplicating the

This module is a adaption of Andreas Lauser's OpmParseDuneModule
in opm-material, modified to handle the more sparse info provided by
the other modules as well.
make the c++-2011 feature set of GCC 4.4 mandatory

we now produce an error even if the module in question does not
actually use some of these features.