Specify dir. layout and stylesheets in common templates

These options should be common to all OPM modules to get the same look
for the generated documentation.
Only add option for shared libraries once

The way the test was done previously, it was added for *every* option
after `--enable-shared`, not only that one.
Allow to search for multiple libraries in package

Some packages are split up in several library files, where each of them
doesn't have their own CMake find-module. So we cannot put this list in
the prerequisites. Unlike the headers, where we just add the directory,
all the libraries must be explicitly named on the link line. Thus, we
should allow to specify more than one name in the lib parameter.

The first name specified is designated as the "primary" library and is
assigned to the _LIBRARY variable; the others occur in _LIBRARIES as if
they were prerequisites.

Note that the build system cannot replicate this setup itself; it always
assumes that we are building (at most) one library from the source
files.
Added CMake find modules opm-parser and cjson
Added opm-parser-prereqs.cmake
Updated modules for Findcjson and Findopm-parser
Updated modules to find Opm-parser
Merge pull request #88 from bska/088_cmake

Synchronise build system with opm-core
Enables FastAMG for dune-istl version >=2.3, too.

The HAS_DUNE_FAST_AMG is only available in the 2.2 cmake branches.
This patch checks whether dune-istl is of version 2.3 or higher and
in this case activates FastAMG, too.
Added missing include for version check
Merge pull request #90 from blattms/fixes_fastamg_with_dune-istl2.3

Enables FastAMG for dune-istl version >=2.3, too.
assembleDynamic(): Fix out-of-bounds indexing in children

In the interest of reducing the number of allocations/deallocations,
the 'rhs' and 'gflux' arrays are allocated once (of maximum size,
'max_ncf_') at the start of assembleDynamic().  However, method
buildCellContrib() implicitly assumes that 'rhs' and 'gflux' are
sized according to the number of interfaces on a given cell.  This
discrepancy leads to out-of-bounds indexing unless all cells have
the same number of interfaces.

Explicitly resize the 'rhs' and 'gflux' arrays for each cell in
assembleDynamic() under the assumption that no additional memory
operations occur during vector<>::resize() if the .capacity() is
large enough.  This way, buildCellContrib() will only inspect the
appropriate number of array elements, i.e., those that correspond to
the current number of cell interfaces.

This bug was present for a *long* time.

Superb detective work by: @akva2
Suggested solution by: @atgeirr
computePressureAndFluxes(): Fix out-of-bounds indexing

In the interest of reducing the number of allocations/deallocations,
the 'pi' and 'gflux' arrays are allocated once (of maximum size,
'max_ncf_') at the start of computePressureAndFluxes().  However,
those variables are subsequently used in way that assumes that
variables are sized according to the number of interfaces on a given
cell.  This discrepancy leads to (semantic if not physical)
out-of-bounds indexing unless all cells have the same number of
interfaces.

Explicitly resize the 'pi' and 'gflux' arrays for each cell in
computePressureAndFluxes() under the assumption that no additional
memory operations occur during vector<>::resize() if the .capacity()
is large enough.  This way, the std::transform() calls will only
reference the appropriate array elements, i.e., those that pertain
to the current number of cell interfaces.

This bug was present for a *long* time.

Detective work and suggested solution by: @atgeirr
Merge pull request #92 from bska/fix-out-of-bounds-indexing

Fix out-of-bounds indexing in IncompFlowSolverHybrid
fix test for HAVE_QUAD on some instances of ubuntu 13.10

I haven't figured out why this happens, but on one of my computers
running kubuntu 13.10 g++ says the following if one tries to use
quadruple precision math:

/home/erne/src/ewoms/ewoms/common/quad.hh: In static member function ‘static quad std::numeric_limits<__float128>::min()’:
/home/erne/src/ewoms/ewoms/common/quad.hh:52:14: error: unable to find numeric literal operator ‘operator"" Q’
     { return FLT128_MIN; }

since this happens only on this machine and only with the c++ (but
not the C) compiler, i suppose that this is either an upgrade issue
with kubuntu or an issue with the ubuntu gcc stack. Strangely enough,
my other kubuntu machine does not have a problem with that...

In any case also testing for assignability of constants and using the
C++ compiler for the quadmath test won't hurt...
Changed the check_cxx_source_compiles() in Findopm-parser to look for Deck.hpp; Parser.hpp had uneccasary complicated interaction with cJSON
build system: prevent endless loop when using dunecontrol

this seems to be a bug in cmake 2.8.10.2: if the user sets the
CMAKE_CXX_COMPILER variable for a build directory where this variable
has already been set, one gets an endless loop. This stings especially
if using the dunecontrol compatibility layer as the compiler flags are
unconditionally set via the CXX_FLAGS environment variable in the
options file. Running duncontrol on a module twice will thus trigger the
infinite loop if some compiler flags are set by the user.

The solution is relatively simple: Delete the CMakeFiles directory
before calling cmake. for the dunecontrol compatibility mode, we do
this in the configure script. For details about the cmake bug, see
http://www.cmake.org/Bug/view.php?id=14119
configure script: also delete the cmake cache

This replicates the autotools behavior and was suggested by Roland
Kaufmann.
configure script: add a stub implementation for the --config-cache argument

so far, it is only a flag which prevents the cache from being
deleted. To warn the user about a potential infinite loop, a warning
is printed if this flag was specified and some compiler or some compiler
flags were set by the user. This idea was proposed by Roland Kaufmann.
include the latest review comments by Roland Kaufmann