feat: implement named stoichiometry and advanced event options for AntimonySerializer

[dyrpsf]

Description

This PR acts as a direct follow-up to the Phase 1-3 implementation merged in #305. It addresses the advanced edge cases and feature requests highlighted by @luciansmith during the initial review, ensuring the serializer can handle complex SBML models cleanly and token-efficiently.

Key Updates

• Named Stoichiometry: Added logic to toAntimony(Reaction r) to check for and serialize named stoichiometries (e.g., dynamically mapping to n S2 => S3 if the SpeciesReference has an ID).
• Advanced Event Options: Expanded toAntimony(Event e) to support complex event configurations:
  • Delays (delay=...)
  • Priorities (priority=...)
  • Initial Values (t0=false)
  • Persistence (persistent=false)
• Token Efficiency: The serializer strictly respects SBML defaults. Options like t0 and persistent are only appended if explicitly set to false, keeping the resulting Antimony string as concise as possible.

Testing

Expanded AntimonySerializerTest.java to cover these new edge cases. All tests are passing cleanly (BUILD SUCCESS).

With these advanced features in place, the underlying serialization logic is fully complete and ready to be adapted into the upcoming TreeWalk Visitor pattern we are discussing in #262!

[dyrpsf]

@draeger, @luciansmith - Just pinging you both here since this PR specifically implements the advanced edge cases we discussed at the end of #305!

Whenever you have a moment to review the logic for the named stoichiometries and event formatting, let me know if it looks good or if any tweaks are needed!

[luciansmith]

That's not actually the correct syntax for delays! It's:

at S1-5 after B>3: x = 4

i.e. '[formula] after'

Are you ensuring that the produced Antimony is correct by trying to parse it with libAntimony? And then ensuring that libAntimony gives you essentially the same SBML when round-tripped? It might help with things like this.

[dyrpsf]

That's not actually the correct syntax for delays! It's:

at S1-5 after B>3: x = 4

i.e. '[formula] after'

Are you ensuring that the produced Antimony is correct by trying to parse it with libAntimony? And then ensuring that libAntimony gives you essentially the same SBML when round-tripped? It might help with things like this.

Ah, thank you so much for the correction! I completely misunderstood the Antimony documentation regarding the delay syntax. at [delay] after [trigger] makes perfect sense.

Regarding your question about round-trip testing with libAntimony: that is a fantastic suggestion. Currently, the JUnit test suite in JSBML is purely doing string/regex matching against expected literals since JSBML is a pure Java environment. However, moving forward, I will definitely use the Python libantimony bindings locally to manually validate these complex strings and ensure they parse and round-trip correctly!

I will push a fix for the delay syntax right away.

[dyrpsf]

@luciansmith Fix pushed! The tests are passing cleanly with the updated at [delay] after [trigger] syntax. Thanks again for catching that and for the tip on using libAntimony for round-tripping!

[draeger]

A few minor change requests about formatting only.

[draeger]

I'll merge this now and we can add an interface collecting Antimony keywords later.

[dyrpsf]

Thank you for the merge, @draeger!

Funny timing - I actually just finished building that exact AntimonyConstants interface locally right as you merged this! Since the code is already fully written and tested, I will go ahead and open a quick, separate PR for it now so we have that clean architecture locked in.

Update: new PR : #311 .