For instance, following non-composite relations.

Closes #15770380.

One might want to registered different IClonable adapter (for different
selection context), and we only need to make sure that registered clone
relation information (rtype, role) are all consistent.

Otherwise we sometimes get cache issue, in particular with assertCountEqual
strange comparison algorithm.

The latter do not work with CubicWeb 3.23.

The latter does not work with Python 3.

as it may occurs during migration.

Closes #13171946

without risk :/

Closes #7166911.

So that it can be used in modules not automatically reloaded without problems.

Closes #6304702.

beside performance and consistency purpose, it will avoid to call recursivly the
clone hook if the cloned subtree contains 'clone rtype' relations. This has
caused infinite recursion problem in a client application, though I've not been
able to reproduce it in a test.

This can be an alternative to the 'clone' action, in particular when the
'edition' form of the entity to be cloned is not readily usable (e.g. needs
tweaking to hide inlined sub-forms, etc.).

This is not ready for inclusion and was backported from client
application to soon.

Thus grouping related things together.

Otherwise the assertion in __registered__() is hit at db-init step.

This method returns a dictionary mapping entity type to composite relation
information allowing to walk the schema graph upstream from these entity
types.

* `parent_relations`/`child_relations` are used to get relation information
  from an entity type.
* `parent_structure`/`child_structure` return the full structure of the
  composite graph, this structure will change later on to conform to the
  "definition" methods.
* `parent_related`/`child_related` yield information about related entities in
  the composite graph either from the parent or child perspective.