[GC] Simplify mark_slice function
[GC]  factorize short-circuiting of Forward tag
[GC] move the cleaning of the weak arrays in a new phase

     A value disappears from a weak array only when it really becomes unreachable.
     Previously it was not the case if:
     - the value is referenced by two weak arrays and during the incremental cleaning
       one weak arrays have been cleaned and the other is accessed,
     - the value has a finalizer and the finalizer make it alive again.
[GC] add full-featured ephemerons in an inefficient way

     - use the generic abstract tag like weak pointers
     - a weak pointer is implemented using an ephemeron (one additionnal word)
     - add for every full GC a complexity of O((n+m)*(m+1))
       with m the number of pure ephemerons,
            n the number of ephemerons used as weak pointers
     - multiple keys, modifiable keys
[Hashtbl] add a getter for randomize
[Ephemeron] add the module in the stdlib
[GC] shortcut clean phase when possible
[GC] make ephemerons more efficient

     During one mark phase instead of iterating on every ephemerons every time,
     we don't iterate on the one which data is alive (not white) or at none
     (weak pointer).

     That give us a complexity in O(n*(p+1))
     with m the number of ephemerons,
          p is the maximum of the distance to an ephemeron from its nearest root
          p = max_{e \in ephemerons} min_{r \in roots} distance(r,e)

     One worst case is when ephemerons e_1, ..., e_n are linked
     e_1.data = e_2, ... e_{n-1}.data = e_n but they have been created
     in the reverse order and are iterated from e_n to e_1, O(n*n). In
     order to mitigate this the ephemerons are automatically sorted
     during mark in the order they are triggered. So during the next
     marking phase the ephemerons will be iterated from e_1 to e_n
     giving a complexity of O(n).
[GC] During mark phase iterate on the ephemerons in specific loop