Pack limitations

[emorice]

• ~We can't load a parametrized generic, which we need for Reply and is currently done with custom magic.~
• [ ] More generally, the whole Reply thing has a pattern -- starting to parse and extracting info about the type dynamically in a non-trivial way -- we did not touch yet.
• [x] To replace simpler uses, the top-level load should work with Result and reject extra frames
• [x] To replace UnionLoader, we may need a top-level interface to that too.

[emorice]

The interface glue was done in 7b6f6f35092516cd6adbf8de17b225ea0ba4e71d. The generic thing is actually not really needed it seems.

On the other hand, our change of approach for unions calls for more redesign. Classically, while for loading you would need the target type, for dumping you only require the object. With our current union implementation, this still works because a class has an endogenous "type key" independent of the union it is in. With pack's way of looking at unions, this is not possible anymore because the key does depend on the "enclosing" union, so the calling code will have to adapt.