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.
We should be able to avoid the "array of ByteCode" → "tuple of SmallInt" → "array of ByteCode" redundant conversion here... Not sure if it can speed things up further. But that may require serializing the code into a ByteString and serializing it (breaks file format?), or reading the private `_codeBlock` from CodeArea.