Formally describe bundled and triggered changes (workflows)

KGCL has the concept of

- [kgcl:ComplexChange](http://w3id.org/kgcl/ComplexChange)
- [kgcl:SimpleChange](http://w3id.org/kgcl/SimpleChange)

Simple changes are atomic at the level of KGCL. E.g. [kgcl:NodeMove](http://w3id.org/kgcl/NodeMove) could be broken down into a removed edge and add edge. However, NodeMove is still considered atomic/simple (it just so happens that there are potential *rewrite* rules for some change types). And of course at the RDF level this may involve many triples but that doesn't concern us here

Currently some KGCL implementations will trigger multiple changes from a single change. For example, in oak running apply on obsoletion will trigger removal of logical axioms and renaming as per (not particularly formally represented) OBO best practice, and similar to existing 'workflows' in Protege. It seems reasonable that we should try and formally represent this common workflow in KGCL.

In fact for obsoletions, the [kgcl:Configuration](http://w3id.org/kgcl/Configuration) class allows for the specification of an obsoletion policy, implemented as [ObsoletionPolicyEnum](https://incatools.github.io/kgcl/ObsoletionPolicyEnum/) - but there is no formal connection between the PVs and the logic.

Other ontologies may have more bespoke rules. See for example https://wiki.geneontology.org/Ontology_meeting_2024-04-08#Triggering_multiple_actions???

I don't think it makes sense to represent specific ontology rules in KGCL, but we may want some kind of mechanism for representing rules in general.

Currently the semantics of things like diff are not well defined here. I think when doing a diff we want a way to optionally "roll up" triggered changes. E.g. the renaming of "foo" to "obsolete foo" is not interesting in the way other renames are, same with "edge deletions". Currently oak hardwires a rule that these are ignored in the diff but this is not very satisfactory.

I propose we include a slot "triggers" or "triggered by" that could be used to better represent at the instance level triggered changes. This allows for a separation of concerns. diff calculation could infer these given two ontologies and an obsoletion policy (for example). Diff reporting could simply report these according to user preference.

We may also want to consider a rule language. e.g. to say "if change of type X happens, and the instance x has value v, then trigger change of type Y...". There are many interesting directions to go here but interesting is not necessarily good, we want this to be easy to implement in both oak and java-kgcl. Something like SPARQL construct would be easy to implement but would we run into expressivity issues?

Review the existing kgcl:ComplexChange, kgcl:SimpleChange, kgcl:Configuration, and ObsoletionPolicyEnum concepts, along with the current diff and workflow behavior described in the issue. Define a general representation for triggered or bundled changes and clarify how diff reporting should expose or roll them up, while keeping implementation feasible for oak and java-kgcl.

Written by the indexing model from the issue text.