Improve the Property.registerAggregate API

* So it only needs the aggregate property name and list of fields,
  instead of having a lot of duplication for unneeded flexibility.
Add back the Panel files by copying them from Mozart 1
Introduce the necessary properties to run the Panel

* The build is simple as this is a single functor.
* The "Problem Solving" tab is not working yet.
Sort aggregate properties by alphabetical order in Property.oz
Add needed properties for the Panel "Problem Solving" tab
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.
Add a VM module, and move OS.newVM to VM.new

* We register VM in DefaultURL to allow "import VM" without explicit location.
* The module is only be available in boostenv, since it relies on BoostVM.
Add the ReifiedVM type, which is a reference to a VM

* Used to Send messages to another VM.
* Currently the ReifiedVM itself implements PortLike,
  we might use a level of indirection.
* VM module functions now return ReifiedVMs.
Implement VM Ports via pickling in the heap!

* We allow to get only once the stream on VM.stream to avoid leaks.
* The sending without inter-VM synchronization is accomplished
  by pickling the value, dumping that to a std::vector allocated on the heap
  and adding a task via targetVM.postVMEvent() which unpickles the value
  from the std::vector and binds it in the stream.
* We use a ReflectiveEntity to represent a VM,
  and intercept {Send VM V} to pickle V first.
  (much cleaner than calling Pickle.pack in C++ code)
Rename VM.stream to VM.getStream

* to reflect the fact we can ask for it only once.
rename BoostBasedVM to BoostEnvironment

* Because now it really is just an environment,
  has no VM functionality (except creating them),
  and just runs the IO thread.
* Impact is relatively low for a rename,
  showing usage is mostly access to the BootLoader
  and the io_service.
Add VM.ncores
add ReifiedVM to the ValueEquatable interface