Implementation of a C++ Pickler

About 60 times faster! (and 50x faster inter-VM messages)
*The dual of my old reverted change to use the Oz unpickler*

@sjrd Could you review?

The Oz Pickler has been entirely removed and the build seems fine so we shall have a decent large scale test for it. Finer tests have been added as well.
They should have the exact same behavior and produce the same number of bytes, only physical order of serialized entities and indexes may changes due to 3 instead of 5 steps to pickle (see efb577db6).
Deduplication of features, arities and builtins is implemented as well as waiting on read-only vars and throwing an exception listing the resources if any.
Deduplication of `patmat*` is not done as they are so rare (not produced by the current Oz compiler).
The tell/seek hack has been removed in favor of string-like objects with known length.

A couple questions:
* ByteString's are not pickle-able (they seem to be in Mozart1), is it expected?
* Chunks and therefore functors, classes, etc are never == with `{Unpack {Pack Chk}}==Chk`. Is it expected?
* Why the Oz pickler did first "everything but chunks/abstractions" then "chunks/abstractions"? Do some of the latter need the former already unpickled? (they both used `DoPackOne`)
* In the same domain, how do records *need* bound arities, and arities their label and features? I could not find easily where we expect these entities to not be unbound variables although there clearly must be some place as we need to sort features for instance.

Running platform tests is much faster as they now use the C++ unpickler. Compilation should be improved significantly as well as pickling is much faster.
1. BootSerializer is only used in Pickle.oz and NewAssembler, where in latter it's an "abuse" to count `patmatcapture`s. I don't know if BootSerializer it is supposed to be used outside of the standard library.
2. One could check the endianness before deciding if a `memcpy` is enough, or we need to flip the bytes. Talking of which, are we sure the VM is really endianness-independent before this change?