Should Apollon have a plugin API for custom diagram types?

[FelixTJDietrich]

Companion to #752.

Context

This is a more specific follow-on to the discussion about Apollon as an integration target.

Today, adding a new diagram type means working inside the engine: registering elements, rendering, palette entries, and property editors across several internal files. That is fine for us as maintainers, but it means anyone else who wants a custom diagram type has to fork the whole editor. The BESSER team added several diagram types (agents, GUI, quantum circuits, and more) this way, inside their fork.

A plugin API would let a third party register a new diagram type, along with its elements, rendering, and editing UI, from outside the library and without forking.

Worth weighing honestly

For

• It is the structural fix for the fork problem. It is the thing that would let an integrator stay a consumer of @tumaet/apollon rather than a fork of it.
• It would make Apollon a real platform for building modeling tools, not only an editor.

Against

• It is a large, ongoing commitment. A plugin API turns a lot of internal seams (rendering, serialization, palette, property editing) into public contract that we can no longer change freely.
• Those internals currently change as the engine evolves, and that freedom is valuable to us.
• So far we know of one integrator who needed this, and they have already forked.

The real question first

This probably comes down to Apollon's identity. Are we a teaching and assessment editor that others are welcome to fork, or an extensible platform that others build on top of? Those imply very different amounts of work, and a plugin API only makes sense under the second. Rather than design the API in the abstract, it would be good to agree on that direction first.

Thoughts very welcome, particularly from anyone who would actually use a plugin API.