Use the Opm::EclipseGrid class instead of the deck directly

this has the advantage that the gazillion ways of specifying an ECL
grid are abstracted away, and thus e.g. using D{X,Y,Z}V is
automatically supported. Also, if additional grid construction methods
are implemented in Opm::EclipseGrid, these will automatically
supported by dune-cornerpoint as well. (If the API for
Opm::EclipseGrid does not change, that is.)
Merge pull request #90 from andlaus/use_EclipseGrid

Use the Opm::EclipseGrid class instead of the deck directly
fix build on GCC 4.4

the usual problem: GCC 4.4 sometimes has problems to implicitly cast
std::shared_ptr<Foo> to std::shared_ptr<const Foo>. sorry for the
hiccup...
Merge pull request #101 from andlaus/fix_build

fix build on GCC 4.4
fix usage of the ACTNUM keyword exported by EclipseGrid

it turns out that EclipseGrid::exportACTNUM() produces a vector of
zero length instead of an all-1 one of the size of the logically
Cartesian grid if ACTNUM is not set.

Strangely enough, this worked if libstdc++'s debug mode was not
enabled. (maybe because dune-cornerpoint does not consider ACTNUM?)
fix incorrect C-pointer ACTNUM handling

these C-style arrays can be NULL!
Merge pull request #102 from andlaus/correct_actnum_usage

fix usage of the ACTNUM keyword exported by EclipseGrid
Changed EclipseGrid() construction

If the deck does not have the RUNSPEC section (nx,ny,nz) are read from
the SPECGRID keyword in the GRID section.
Merge pull request #103 from joakim-hove/alternative-EclipseGrid

Changed EclipseGrid() construction