Do not use the second MemoryManager in Serializer

* Now that we handle MemoryManager::getMoreMemory(), it is no more needed
  (memory wise) to use the other MM and it actually might be unwise to do so
  (it could allocate an extra heap which might not be needed if there is no GC).
* Also, keeping this would make any sharing of the secondMM more complicated.
* The Serializer does not depend anymore on such low-level memory details.
Align memory usage numbers to ease comparison in GC debug output
Introduce the --min-memory option and compute gcThreshold as in Mozart 1

* Compute the threshold as explained in
  http://mozart.github.io/mozart-v1/doc-1.4.0/system/node65.html#section.property.gc,
  that is gc.threshold = gc.active * 100 / (100 - gc.free).
  Of course, we shall always have heapSize >= gc.threshold * (1 + gc.tolerance) / 100
  (this is not implemented in this commit for clarity).
* We reduce gc.tolerance to 10% (from 20%) to avoid
  a too large allocation or a too low gc.threshold.
* Also add heapSize which maps to property "gc.size" and is
  between minimalHeapSize and maximalHeapSize.
* VirtualMachineOptions must be in core-forward-decl.hh
  because vm-decl.hh includes properties-decl.hh, so
  properties-decl.hh can not include vm-decl.hh.
* Requires PropertyRegistry to be constructed directly with the VMOptions,
  to set the essential GC parameters for heap management ASAP.
* BoostEnvironment now keeps the VMOptions and pass them for each new VM.
Introduce dynamic heap management

* improves the memory footprint and does not increase execution time.
* heapSize doubles every time we are running out of space after a GC
  or allocated a too big chunk (>= 10%) outside of the _baseBlock.
* allocations when the heap is too filled are done with regular malloc,
  and promptly freed after as we request a GC.
* --min-memory and --max-memory are respected.
* allow to run 2 gc consecutively. This happens when we need to change
  the heap size. As the only reliable measurement is the activeMemory,
  which is only available after a GC, and we need to do another GC
  to transfer the heap to the bigger block.
Guess the next active size when doing an allocation outside of the base block

* Avoids the double GC pattern for huge allocations.
  It was especially bad since it most likely meant
  doing another extra allocation during the first GC.
Validate given minimal and maximal heap sizes
Limit gcThreshold to maximalHeapSize - tolerance

* Also pass explicitly activeMemory to computeGCThreshold(),
  so it is clearer and we need not to change config.activeMemory.
Fail clearly when we used too much memory