during element insertion it is necessary to find all face-neighbors of
the element. There was an old O(N^2) algorithm which just looped through
all exisiting element to find the neighbors. This is prohibitively
expensive for large grids. There was an O(N) algorithm which stored a
lot of information in some helper data structures to speed up the
neighbor search. I didn't understand in detail what it is doing, but I
have the impression that it somehow stores the vertex-element relation
for all vertices which might still be needed...

This patch provides an alternative implementation of an onther O(N)
algorithm, based on standard C++ data structures. To speed up the search
we maintain a hash-map (i.e. unordere_map) from a face to an
element. Faces are identified by a sorted list of their vertices. When
we ancounter a face the first time we store the "inside" element in the
map. When processing the neighbor element at a later stage, we detect
that the hash-map already contains an entry for this face and
this (previously inside) element is exactly the required neighbor. Now
we can safely remove the entry from the map, as we know that a face can
only the found twice.

Feature/enforce dynamic memory allocmodel

See merge request !94

in particular we removed the variables bottomtmpmem, usefreelistmemory
and freelist_end_mark and cleaned up the code using them.

the virtual heap management was only used for user data.
As dune handles user data differently, we can drop this code.

drop ResetCEstatistics, PrintCEstatistics, DefineMGUDBlock,
     FreeMGUDBlock, and GetMGUDBlockDescriptor

try fixing heap cleanup

fixup bottom/top heap

bugfix

check_of_getcallstack and check_of_putcallstack were used to keep track
of calls to the memory management. As most of it is now defered to the
libc calls, we don't need these variables anymore.

 we removed:
 ... HeapSize HeapUsed HeapFree HeapFreelistUsed HeapTotalFree HeapStat

 - we removed these memebers and updated the management code accordingly
 - most status functions in heaps.cc are now a NOP and should be removed

we have kept a few of them in order to keep track of where we could further
simplify the code and remove old code...

the member was used to keep track of the heap memory, but since we use
the system heap the variable is always 0.

these variables were used to chnage the memory mangement of a particular
UG instance. As these variables were global, this could only work by
coincedence. We moved them to the heap, as this is the memory mangement
unit for the multi grid.

  - we compute some sizes, but the name was misspelled, thus we always used the default

Cleanup

See merge request !98

The rank will no longer be readily available as a global variable once
a context object for PPIF is used.  Also MPI implementations already
provide a way to tag output with the rank of processes, for example
OpenMPI's `mpirun` has the `--tag-output` and `--output-filename`
options.