DG implementation
Planned features
 Discontinuous Galerkin implementation with arbitrary choice of (polynomial) shape functions
 arbitrary order
 prefinement over macroelements
 matrixfree operator evaluation
 weak form generation via HFG
 evaluation of functions and linear functionals for righthand side assembly generated via HFG
 direct volume to volume communication (interface primitives not used)
 SIP for Poisson
Probably also(?)
 hpmultigrid (maybe also projection into continuous element space?)
 weakly imposed boundary conditions
 upwind operator
Roadmap

Volume DoF data structure + DGFunction class w/ basic indexing functionality 
DGOperator class, apply, toMatrix() 
mass form, interpolation 
linear form for RHS 
Laplace form (SIP, interface integrals) 
communication (PackInfo etc.), macrointerface integrals 
inhom. Dirichlet BCs. 
higher order shape functions 
HFG refactoring and fixed DGForm API 
3D extensions 
padaptivity
Possible optimizations / open refactoring / dev notes

optimize evaluation by precomputing and storing trafo matrices on each macroface / macrocell (it's recomputed every time in the evaluation function) 
make all methods in DGBasisInfo const 
give DGForms the following virtual methods 
isConstant()
: true if the form is constant over the macro  so optimization can be applied 
isInlined()
: true if entire kernel is available 
onlyInnerIntegrals()
: true if only volume integrals are nonzero (think mass matrix)  this allows to implement efficient(?) local inversion of the blockdiagonal system without communication


probably we should not double the information about the local polynomial degree in each macro in the DGFunction AND VolumeDoFFunction 
optimize VTK evaluation by new DGFunction::evaluate( faceID, microIdx, faceType, ... ) method that skips looking for the microelement  we know already which one we are targeting (this is not only an optimization but also fixes slightly incorrect visualization) 
what to do with the DoFType 'flags'? 
implement affine elementlocal evaluation directly in HFG 
Optimize HFG trafo matrix computations by letting it know which element vertices belong to the interface. This should allow for some cancellations since some of the input points are actually equal. 
There is an issue if the boundary macros are marked as 'Inner' as done for Stokes usually  since then the DGOperator 'thinks' that there must be another volume macro on the other side. Boom. 
Instead of resizing the element matrices, the HFG should rather assert that the size is already correct.