[Ordering] Export size type using standard size_type syntax in Ordering traits
[ISTLMatrixBackend] Move pattern construction policy into matrix backend

In preparation for supporting alternative, more efficient pattern
construction methods, this patch moves the code that is responsible for
the pattern creation and matrix allocation from ISTLMatrixContainer to
the matrix backend class that is passed to the GridOperator. That way,
the policy is always easily accessible, regardless of where exactly in
the code the matrix is being created. Moreover, the container now
optionally exports some statistics about the pattern creation process,
which might be helpful when the process contains some tunable
parameters. The changes in detail:

- ISTLMatrixContainer now takes a fourth template parameter "Stats" for
  the type of statistics object.

- Backends now have to export the type of the pattern object for the
  GridOperator, as the type of that object now depends on the backend
  and not just on the container.

- The GridOperator now imports the Pattern type from the Backend.

- The GridOperator now exports the matrix backend instance for access by
  the matrix container during pattern creation.

- ISTLMatrixContainer now possibly exports some statistics about the
  creation of each "leaf" BCRSMatrix. In order to keep complexity down
  for the average user, the returned object is a single statistics
  object if there is only one BCRSMatrix involved and a std::vector of
  statistics object in row-major order if there are multiple.

- Provide the required pattern template in dense backend.
[ISTL] Add PatternStatistics class

PatternStatistics will be used by the new BCRS pattern construction
method to relay back tuning-relevant statistics about the construction
process to the user.
[ISTL] Add new backend class with more efficient pattern construction

The new construction method re-uses the ideas from the new implicit
construction mode of the raw BCRSMatrix, but splits the process in two
again by separating pattern creation and matrix assembly. There are two
reasons for this split:

- In parallel non-overlapping mode, we have to collect some extra
  information during pattern creation. By keeping pattern creation as a
  separate process, this data collection does not slow down standard
  jacobian assembly.

- The split approach is more robust than the implicit mode of the
  BCRSMatrix, which can fail with an exception if the user
  underestimates the number of nonzero entries per row. Our approach
  only experiences a performance degradation during pattern creation in
  that case.
[Tests] Modify testpoisson to generate binaries for both new and old
ISTL matrix backends