Fix (wrong) clang 3.4 warning (happens on Mavericks)

* Might be somewhat related to http://fr.it-usenet.org/thread/11425/24401/
* Seems due to the usage of both constexpr and inline.
* We simply inline the functions as they are so trivial.

In file included from .../mozart2/vm/vm/main/serializer.cc:25:
In file included from .../mozart2/vm/vm/main/mozart.hh:28:
In file included from .../mozart2/vm/vm/main/mozartcore.hh:28:
In file included from .../mozart2/vm/vm/main/mozartcore-decl.hh:36:
In file included from .../mozart2/vm/vm/main/typeinfo-decl.hh:35:
.../mozart2/vm/vm/main/lstring-decl.hh:167:34: warning: inline function 'mozart::mut::LString<unsigned char>::slice' is not defined
      [-Wundefined-inline]
  inline constexpr const LString slice(nativeint from) const;
                                 ^
.../mozart2/vm/vm/main/bytestring.hh:127:44: note: used here
  LString<unsigned char> haystack = _bytes.slice(fromOffset);
                                           ^
1 warning generated.
Merge pull request #171 from eregon/clang_warnings

Fix (wrong) clang 3.4 warning (happens on Mavericks)
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
Use ozCall() instead of adding a layer of ReflectiveEntity

* Allows implementing == and printReprToStream() much more easily.
* Less indirection (ReifiedVM is already an abstraction over the real VM).
* But more code of interactions between C++ and Oz, most notably
  a Property and a strong dependence on Pickle being loaded.
  (loaded only when loading the VM module though)
Add {VM.list} so the child VM can easily know its parent

* Current order is spawn order, might become unspecified though.
* Does it needs some locking? std::forward_list::emplace_front()
  should not touch others elements (only the head ptr) so it should be fine.
Add {VM.closeStream}

* Something similar is necessary for correct termination detection.
* What happened is the main Oz Thread waits on the stream,
  and nobody is there to wake it up so the VM just shuts down.
  This is similar to async IO, so we use the _asyncIONodeCount counter.
  But if we never call getStream(), we wish not to wait for it,
  since of course we can not wait on it.
* Applications using {VM.getStream} should now use {VM.closeStream}.
* TODO: What about GC and ProtectedNode?