Resolve a terminology conflict: event-watching vs state-changing causes

[nolar]

Fix the terminology mess between the event-watching and state-changing causes & reactions.

Issue : #194

Description

Since the event-handlers were introduced, there was a terminology chaos in the framework. Specifically, the "event-handling" routines had different signatures than the "cause-handling" routines, despite doing exactly the same, in almost the same way. This became very obvious during the throughout type annotation in #200.

This PR changes the internal terminology both for causation and for handling of such different causes:

• All ex-"event-handling" routines were renamed to "event-watching" causes and routines -- as they trigger the reaction directly from the event watching streams.
• The ex-"cause-handling" routines were renamed to "state-changing" causes and routines -- as they trigger the reaction based on the detected changes of the object's state according to the framework's logic; or to no reaction if the state is not changed, regardless of the streamed events.

Internally, the causes are also converted to a more suitable data structures: dataclasses (Python 3.7+). This allows their inheritance, unlike with the namedtuples.

The legacy methods and properties are left in place for backward-compatibility of semi-public interfaces: the registries were exposed to the users, so they could be used; but these specific methods were not documented and were used mostly internally (but this cannot be guaranteed).

Actual purpose: This PR is extracted from the following PR with the auto-guessed implicit owners for hierarchy building: it will require identifying the current object in a similar way in all kind of handlers, regardless of their nature -- hence, they all should have a "cause" with the same core properties.

Types of Changes

• Refactor/improvements

There are no behaviour changes in theory. In practice, some semi-public methods could be broken: they are untested, but they are also not supposed to be used externally, and are not used internally.

[zincr]

🤖 zincr found 0 problems , 1 warning

ℹ️ Large Commits
✅ Approvals
✅ Specification
✅ Dependency Licensing

Details on how to resolve are provided below

---

Large Commits

Checks all commits for large additions to a single file. Large commits should be reviewed more carefully for potential copyright and licensing issues

This file contains a substantial change, please review to determine if the change comes from an external source and if there are any copyright or licensing issues to be aware of

• ℹ️ kopf/reactor/registries.py had +100 lines of code changed in a single commit
  Please review this file to determine the source of this change