When one add some non-composite relation to be followed, it should be
automatically added to cw_skip_copy_for else it will be both deep copied and
swallow copied, as demonstrated by the amended test.

We have to consider it at every levels of the container tree, not only for the
top-level entity.

While doing so, it sounded good to move creation of the list to a cached
property to avoid redoing this for each cloned entity of the tree.

cw_skip_copy_for on an entity class allow to skip non final relations in
Entity.copy_relations(). Extend this behavior to final relations in compound
clone, this allow to skip (i.e. not set) some attributes on the cloned
entities.

This can occur in real cases when etype is related to his parent by multiple
optional relations where only one could be filled. We could generate 'OR'
expressions but for now this is not handled.

The compound graph may be used to generate RQL expressions that can be used in
permissions. E.g. when permissions depend on permissions on container.

Use a shortest path algorithm to generate RQL expressions from any etype to the
container of the graph using exclusively mandatory relations.
Make expressions more readable by using variables based on etype name.

and write some tests about graph traversal functions.

preventing NoWarningCopyFormView to be selected when expected.

* removed backward compat on structure_def location, broken by moving to
  the new layout

* __pkginfo__ and setup are now flake8 compliant

those are copied using standard Entity.copy_relations method, hence adapter's
skiprtypes should be copied in entity's cw_skip_copy_for to control above
method.

that's at least desired by current usage of CloneAction, let's suppose it's a
fine default.

so any clonable entity relying on the copy form won't have the 'swallow copy'
warning message.

and test it.

we don't want it to appear auto-magically for every IClonable entities

the original intent was to avoid having an automatic 'clone' action appearing in
the UI because some type was adaptable to IClonable. While this is still
desirable, keeping some generic UI tweaks useful to those activating the action
will be better then dropping everything at once.

Being adaptable to IClonable doesn't mean we want a clone action in the UI,
furthermore when it leads by default to the clumsy 'copy' form.

This is information that will need most custom adapters, without doing some more
heavyweight refactorings.

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.