Add new model 2p discrete fracture-matrix model. (reviewed by gruenich)

Dumux-Svn-Revison: 9629
Ported-By: Andreas Lauser <andreas.lauser@iws.uni-stuttgart.de>
Add new file reader Artmeshreader, needed by 2p DFM test. (reviewed by gruenich)

Dumux-Svn-Revison: 9630
Ported-By: Andreas Lauser <andreas.lauser@iws.uni-stuttgart.de>
Add test for 2p discrete fracture-matrix model. (reviewed by gruenich)

Dumux-Svn-Revison: 9631
Ported-By: Andreas Lauser <andreas.lauser@iws.uni-stuttgart.de>
Fix Doxygen warnings introduced by the inclusion of 2pdfm.

Dumux-Svn-Revison: 9633
Ported-By: Andreas Lauser <andreas.lauser@iws.uni-stuttgart.de>
2pdfm: replaced the ArtMeshReader by a ArtGridCreator which is conform with the other GridCreators in Dumux. As a consequence, it is now possible to have a standard Dumux cc-file calling the Dumux start routine.

The FractureMapper is now placed directly into the SpatialParams and not
tunnelled through the problem anymore. Moreover, there are numerous
naming and style changes to make it more Dumux-conforming.

Reviewed by Christoph.

Dumux-Svn-Revison: 9676
Ported-By: Andreas Lauser <andreas.lauser@iws.uni-stuttgart.de>
discrete fracture model: properly port it to ewoms

The model is quite a bit smaller than the Dumux "2pdfm" model, and
currently shares a few limitations with it:

- It only works with the Darcy velocity model
- It is only implemented for two-dimensional grds
- It only works with two fluid immiscible phases

Having said that, some things are working better than for the Dumux
model:

- Energy conservation is supported if requested. (but heat conduction
  along the fractures is neglected; Given the small cross sections of
  the fractures, this is quite likely not a severe issue.)
- It seems to be more correct: If the material parameters of finite
  volumes containing fractures are changed to the ones of the fracture
  in the dumux example, the model behaves _very_ differently than if
  fractures are implicitly handled. (the funny thing is that the flow
  is much faster with implicit fractures, which is physically
  impossible because of the small cross sections of the fractures.)
  The eWoms model exhibits approximately the same behavior in both
  cases.
- Quantities for the fractures (e.g. saturations, porosities, volume
  fractions, ...) written to the VTK output files and individually
  en-/disabled at runtime. This makes understanding what goes on in
  the fractures much easier.
- The initial condition and constraints can be either specified for
  the fractures or for the matrix. If the former, the primary
  variables are automatically calculated from the fracture fluid state.

If the fracture module ought to be used, the grid creator must now
also provide a "fractureMapper()" method. So far, only the new grid
creator which reads ART mesh files provides this method. This grid
creator assumes that an unstructured grid is used. To use it, you need
to set the GridCreator and Grid properties to something like:

SET_TYPE_PROP(YourTypeTag, GridCreator, Ewoms::ArtGridCreator<TypeTag>);
SET_TYPE_PROP(YourTypeTag, Grid, Dune::ALUGrid<2, 2, Dune::simplex, Dune::nonconforming>);

and also include the ewoms/io/artgridcreator.hh header file.
janitorial: update copyright notices in files, remove unused typedefs and enums
fix 'make headercheck'