Protocolize Hook Definitions

[axtimhaus]

As came up with #162, some hook definitions in our profiles and units could be organized in protocols.

I went through the existing code and found nothing in the hook mechanics that could prevent this.

So maybe we shall create a bunch of protocols defining hooks for "all about strain" or "all about contact" or something like that the get the hook defs organized and reuseable (like is already done with DeformationUnit reused by RollPass and RollPass.DiskElement, which shall be split and converted to such a protocol).

[axtimhaus]

Adding such protocols could also replace the hacky HookHost.extension_class mechanic (which is used in very few plugins for now, more like a case study, so the change would not be that breaking if we simply remove it).

This is aimed to solve the problems with hooks defined in plugins, which are not recognized by IDEs (PyCharm in special, do not know about the case in others) and issue warnings about undefined attributes everywhere, which is prone to typos and also just annoying.

I think about something like that:

class MyNewHooks(Protocol):
    my_hook: Hook[float]
    my_hook2: Hook[float]

RollPass.extend(MyNewHooks)

@RollPass.my_hook
def fun(self: RollPass | MyNewHook):
    return self.my_hook2 * 2

[ChRen95]

I strongly recommend that we will focus on that. I would structure it that way, that we describe general material behavior with those protocols like Deformable and so on. That would later make sense when we introduce concepts like Layered or Compressible.

[axtimhaus]

Also on profiles regarding different groups of material data