However 17ba907b which said:

Implement TKey::Hash overloading TNamed::Hash and using TObject::Hash instead.
    The function in TNamed::Hash is not convenient for TKey in case many keys
    have the name but different cycles.

But then was partially reverted (to have TKey::Hash call TNamed::Hash)

Add documentation in TObject::Hash to callout for the need to use CallRecursiveRemoveIfNeeded
in destructors

Return 'true' if we can guarantee that if this class (or any class in this class inheritance hierarchy) overload TObject::Hash it also starts the RecursiveRemove process from its own destructor.

This new field allow to store information about the TClass that can only get
calculated/known at runtime.

Create two members, weak and unique_ptr, as I/O cannot handle variant. So we stream both.
O, and I/O cannot handle weak_ptr, but we really need it, so at least support writing (through THttpServer) by adding a `T*` with the same
value as the weak ptr, and have that streamed. This completely breaks the internal symmetry of TUniWeak, but it should get us started...

E.g. to get non-const access to the top-most TCanvas.