Clean up CreationEvent hierarchy

[Andrew Berezovskyi]

IIRC, in Lyo 2.2.0 we removed the abstract modifier from the ChangeEvent class due to shortcomings in the JenaModelHelper at the time.

I have 3 thoughts:

1. We should make it abstract again.
2. We should create a superclass over Creation and Modification events, for example, a CreationOrModificationEvent. The reason for this is that the TRS 3.0 spec changes the semantics to strip Creation and Modification events of any semantically meaningful distinction. The reason is that many apps in the field violate the existing semantics and we shall codify it. I was against it but it got into the spec text anyway. This way, app developers would be able to check if a resource is an instance of CreationOrModificationEvent, which is in line with the spec text (i.e., you cannot check further for the instance of a Creation event because it may a modification labelled as a creation or vice versa).
3. Make use of the JDK 17 sealed feature and seal both the ChangeEvent class and the CreationOrModificationEvent.

[Andrew Berezovskyi]

As I was experimenting with dynamic proxies in Java that only support interfaces, we also need to extract an interface from each of these classes as well (and bring along the annotations).

[Andrew Berezovskyi]

Breaking because some apps may now depend on the non-abstract nature of the ChangeEvent.