Refactor `AntimonySerializer` to use abstraction and reflection-based design

[dyrpsf]

Background

During the implementation of Parameter and FunctionDefinition support in PR #319, @draeger suggested an architectural improvement for the AntimonySerializer. Currently, the serializer relies heavily on individual concrete class handling—specifically, an extensive instanceof routing chain and manual isSet...() checks for individual attributes.

Proposed Architecture

To reduce boilerplate and improve the scalability of the utility, we should leverage JSBML's existing abstraction mechanisms. By utilizing entry points like writeXMLAttributes or Java reflection (similar to JSBML's toString implementation), we can collect attribute/value pairs and structural information at a higher abstraction level.

For attributes or keywords that differ between SBML and Antimony, a simple mapping layer (such as a lookup table or properties-based configuration) can be introduced.

Implementation Goals

• Base Abstraction Layer: Implement a generic generic serialization method that automatically loops through structural information for an SBase element.
• Keyword Mapping: Create a lookup table to translate JSBML attributes to Antimony syntax where they differ.
• Generic Element Migration: Migrate "flat" components (e.g., Compartment, Parameter, basic Species) to inherit their Antimony serialization almost entirely from the generic superclass logic.
• Custom Overrides: Identify and isolate complex components (e.g., Reaction kinetic laws, Event triggers/assignments) that will still require custom override methods for nested ASTNode math formatting.

Benefits

• Reduces the number of class-specific special cases.
• Eliminates boilerplate attribute-checking code.
• Makes the serializer much easier to maintain and extend for future SBML components.

[dyrpsf]

Hi @draeger,
I am ready to start working on this refactor! Could you please assign this issue to me?