This should partially fix issue #2

erase IOTupleType and addEOCErrors(), add EOCWriterCaller and DataWriterCaller, rename some methods and classes....

# Conflicts:
#	dune/fem-dg/algorithm/caller/datawriter.hh

These changes were needed inside the assembly of the primal matrix
to allow additional discrete functions forwarding to the assembler
which forwards them to the model which is then able to evaluate these
discrete functions.

Mainly, there are two approaches:
1. Use the whole pass stuff (InsertFunctionPass), model caller etc.
2. exchange the std::vector<std::vector<> > structure of evaluation values
   by a std::vector< std::tuple< 'anything'..., std::vector<> > > structure.
   and prepare data on your own.

I followed the second approach which will help to distinct between
pass-based operators and the tuple structure, mainly given by algorithm
creator.
That means: The algorithm creator can still prescribe some variadic
tuples of additional values, the operator decides (based on his implementation)
whether to use passes or handle these information on his own - but the
analytical models do not care about the operators decision.

Short overview on main features/changes:
- Better distinction between a quadrature context (spational information)
  and their corresponding local evaluation regarding this context
- no time()-method anymore: time has to be taken from the analytical model, now.
- Local Evaluations are constructed once (for each element) and each called
  sub routine is now able to 'unpack' regarding up to three different attributes
   * quadrature point (has to be an unsigned int/long unsigned int)
   * passId/Id of tuple (has to be a std::integral_const<int,.> value)
   * basis function number (has to be a signed int)
  via sub script operator[]
   -> disadvantages: always mind the right type, implicit type conversion
      is disabled
   -> advantages: possible to unpack recursively and also return vector/matrix
      like structures. No conversion (ala RangeValues in primalmatrix etc.)
      needed anymore

Known issue: performance loss: This will not be avoidable 100% as models are
more general know, but I will have a look on that later on

model parameters has got ids from 0 ... modelParameterSize-1,
start pass (u) has got id modelParameterSize and so on...

From now on, we assume that all extra parameter args described
in a model a continuous increasing by one (starting from 0).
Use PassIdGenerator together with and 'activation' typedef.
Non used id's are marked by -1 and thus neglected