Store implementations: expose a heterogeneous store API when applicable

(This MR is on top of !1 (merged): the diff will get slightly more precise if !1 (merged) gets merged and this one is then rebased.)

unionFind assumes a homogeneous store (all references created for a given store have the same type). Building this assumption in the API of the Store modules make them less expressive. If we wanted to reuse a store for something else than UnionFind -- this would make sense for StoreTransactionalRef in particular -- then the homogeneous-store assumption would be a major limitation.

(If this criticism sounds like perfectionism, it is! I am working on a new Store implementation supporting full nesting of transactions, and I would like the same code to be usable for unionFind and also reusable for other purposes, so clearly I want a heterogeneous store API.)

In the present MR, we define a new module type HSTORE for heterogeneous store, and we expose heterogeneous-store APIs for the implmentations that support it directly: StoreRef and StoreTransactionalRef. Note that it is not obvious how to convert StoreVector and StoreMap to a heterogeneous store; we show how to do this in a generic way using dynamic type representations, by defining a HStore_of_Store functor in the Store module, but we don't use this to define StoreMap and StoreVector, which remain homogeneous to avoid any extra overhead of dynamic type representations.