add support for packing T::Selection, for classes T which are packable, if T::Selection is defined

Change of structure for packing/unpacking: instead of 'starting' from a Packer, which defines both the packed and transient containers between which it can convert, start from the transient type. This is needed to (automatically) support packing of SharedObjectContainer<T> and KeyedContainer<T>, and can be better extended to support SOA containers as well. In addition, require a freestanding unpack function (as unpacking is 'stateless') to avoid having to meta-program to figure out which Packer type to use.

Add packing/unpacking of SharedObjectContainer and support multiple unpackers for the same persistent type (as the types referred to by PackedRelation are only really known when querying the specified container while re-creating the links) which implies that unpacking now returns a StatusCode which can be used to detect what failed (and, more important, whether failures are recoverable). The latter also is used to simplify the unpacking of relations from particles to primary vertices, as the 'to' side is stored as reference to VertexBase, but the target container contains RecVertex (which inherits from VertexBase). This is now no longer a special case, but dealt with automatically by the above 'recovery' when multiple unpackers are registered for the same packed class ID.

NOTE: one of the side-effects of this MR is that the function get_particles will now return a SharedObjectContainer<Particle> instead of a KeyedObjectContainer<Particle> -- this change of type is transparent to code which uses a Range<Particle> as input (as in that case, the code will automatically 'adapt' to this change), but not to code which insists on using KeyedObjectContainer. As a result, there are two MR in Rec and Analysis which trivially switch algorithms from using KeyedObjectContainer and use Range instead: see Rec!3538 (merged), Analysis!1011 (closed).

Also, to make things backwards compatible when reading older files which contain KeyedContainer<Particle> in locations where now SharedObjectContainer<Particle> is expected, the code will explicitly recognize this situation, read the data into a KeyedContainer in a separate location, and then create a SharedObjectContainer in 'target' location. This may affect (as can be seen in Analysis) the print-out of the TES location of the 'parent' (owner) of the Particle, as that prints the separate location of the owning container and not the location of the container used to obtain the contained object.

NOTE: as a corollary of the above note, the packing and unpacking of selections is explicitly exercised, as the copying of the 'final' output particles to the line specific TES location(s) is done by creating a 'shallow' copy (that is what changes in Rec!3538 (merged) do!), i.e. a Selection, which is then packed into the output file, and thus anything running on the output of Hlt2 or Sprucing which consumes these locations is now consuming a Selection instead of a KeyedContainer. Hence all tests consuming Hlt2 or Sprucing output are explicitly testing this functionality.

NOTE: please note that this MR tends to, if anything, decrease the size of the DstData raw bank by O(1%) (observation based on the Moore tests which require reference updates due changes in the 'Size of serialized data' counter of HltPackedBufferWriter), even though it writes an additional (very thin) layer of indirection, due to increased opportunities to share data and avoid spurious copies.

Needed by Moore!2592 (merged), requires Rec!3538 (merged)