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.heapsize" and is
  kept 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
Allow to pass a functor value to {VM.new}

* Easier to pass the parent VM identifier as well as other data.
* Two separate scrips or VM id comparison is no more needed.
* We Pickle.pack the functor to make it VM-independent.
* We copy the app string in the thread function arguments,
  so memory management is automatic and
  we need not to keep a reference in BoostVM.
Use the return value from VMStarter as feedback
Implement {VM.kill VMIdent}

* std::atomic_bool has a much better API than std::atomic_flag
* We simply requestExitRun() and break from the BoostVM::run() loop.
* VMs are allowed to kill other VMs, so we take care
Set the exit status when killing the last VM

* So legacy code can still use {Application.exit Status} to set the exit status.
Close the VM port when terminating the VM

* the VM thread should handle its own termination, so use postVMEvent().
Move VM termination definitions to boostenv.cc
Cleanly terminate VMs which have finished normally
Make BoostEnvironment's _nextVMIdentifier atomic
Protect the vms list with a mutex

* This is rather heavy weight but it is needed
  if we want the ability to remove vms.
* _nextVMIdentifier needs not be atomic anymore
  since it is also protected by the mutex.
add {VM.monitor OtherVMIdent}
Reorder statements in BoostVM::terminate()
Move the unregistration of the io_service to BoostVM::terminate()
Make the load of _aliveVMs synchronized with the decrementation

* To avoid any possible race condition
Move BoostVM::addMonitor() to the "Termination" section