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.
How would you keep the Serializer compatible, while removing the tuple of SmallInt from CodeArea::serialize() ? For some serialization defined in Oz, the tuple of SmallInt is the simplest thing that works. I would guess, once we have the tuple, that extracting ByteCode is not very expensive.
Making serialize() return a ByteString would be a possibility indeed. It would make CodeArea::serialize() endian-aware but that is probably fine. I shall try that.
I think reading directly from the entity should be avoided. It can not work easily for Oz code and would involve more external and strongly-coupled code to handle CodeArea.