Merge pull request #166 from eregon/bigint

Refactor the BigInt entry points to use standard builders
Remove unused methods BoostBasedVM::setApplication{URL,Args}

* Application URL and args are put in the registry directly by emulator.cc.
Add a BoostVM class to hold what needs a VM in a Boost environment

* BoostBasedVM::boostVMFor() needs to be fixed.
  We could extend VirtualMachine or find
  another smarter way to have constant-time boostVMFor().
* UUID generation should be per vm if we want to avoid locking
  on the random generator.
* Boost classes taking a reference to a BoostBasedVM now take a BoostVM
  since they need to access BoostVM features. An alternative could be to pass
  the BoostVM as the first argument in the different methods,
  but the constructor needs it too and it is much easier with the lambdas.
Let each BoostVM run in its own thread, and the main thread do the ASIO

* We reuse the _conditionWorkToDoInVM condition variable to wait
  efficiently between VM runs since it is unused outside of run().
* Added VMs should be start()'ed but it should not be needed to call run(vm)
  on the main thread, unless the previous VMs died and we want that one
  to outlive others.
Have a saner implementation of BoostVM::forVM(): inherit from VirtualMachine

* Actually, it is quite a similar layout (VirtualMachine storage in BoostVM),
  except now the VM pointer also happens to be a BoostVM pointer.
Wrap the VM initialization process in a lambda

* So we can reuse that code later to initialize other VMs.
* As we are in main() it is safe to pass by reference, but
  we prefer to copy captured variable to avoid any possible
  side-effects between VMs.
Make the VM initialize itself in its own thread

* This is a much simpler and saner design.
* The thread is started at the end of the constructor, and BoostVM::run()
  is naturally blocking since it is executing on the same thread as the caller!
* There is only a single invocation of BoostBasedVM::runIO() in the main thread.
* No more waiting from VM threads, they are doing both initialization
  and running the VM and only do that.
Add {OS.newVM ApplicationURL} to create a new VM!

* A std::string is passed so it does not depends of a particular VM.
* The choice of OS is pragmatic, it might as well be {VM.new AppURL}.
* The storage chosen for the appURL is the BoostVM since it needs
  to be accessible from the thread which might start much later.
* The maximal memory of new VMs is hardcoded right now.
Add a VM argument to VirtualMachineEnvironment::genUUID()

* We need it since random generators (used for UUID generation)
  are not thread-safe (it is undefined behavior to make 2 calls
  in different threads at the same time) and it would yield
  contention and complexity to introduce a lock around it.
* Also, random number (and UUID) generation should be independent in each VM.
* It is a bit confusing to have two genUUID() in VM and BoostVM,
  but since the first is not virtual the call path should be clear.