Separate transformer orchestration from export callback handling

[DanRod1999]

Is your feature request related to a problem? Please describe.
IModelTransformer currently acts as both the top-level transformation coordinator and the concrete IModelExportHandler. As a result, exporter callback methods are mixed into the public transformer interface, and control flows in both directions between IModelTransformer and IModelExporter, including access to exporter implementation details. Consumers cannot easily distinguish orchestration APIs from callback plumbing.

Describe the solution you'd like
Separate the responsibilities of coordinating a transformation, traversing the source, handling exported entities, transforming their data, and importing into the target.

The resulting design should:

• Keep consumer-facing orchestration and intentional customization APIs distinct from IModelExportHandler callbacks.
• Prevent IModelExporter from depending on or calling a concrete IModelTransformer.
• Prevent transformation code from accessing private exporter methods.
• Give the export handler or a dedicated transformation processor ownership of callback behavior rather than merely forwarding every callback to the coordinator.
• Preserve supported exporter injection and provide a clear migration path for transformer subclasses.

Describe alternatives you've considered
A thin forwarding adapter can remove the inheritance relationship while delegating every callback back to IModelTransformer. This improves type separation, but retains the mirrored public callback API and most of the behavioral coupling, so it does not fully address the underlying concerns.

Additional context
Parent issue: #325

Draft PR #345 explores the forwarding-adapter approach and can be used to evaluate compatibility requirements, but the intended component boundaries should be agreed upon before finalizing the breaking API change.

generated with GPT-5.6 Sol

[DanRod1999]

I had copilot come up with some diagrams regarding current architecture and proposed archs:

[hl662]

Why not keep IModelTransformer as the processor component in our workflow? Seems like the name is more fitting that way. The responsibility of the overhead sorta 'singleton' is to coordinate the whole workflow right? why not call it IModelTransformController? I like this decoupling, it's complimentary of my work in my currently active element aspect PR, where I have like ExportProcessor and ExportController and etc. trying to thin out these big 3 classes into more dedicated components. Same with the strategy, I like it. I guess the strategy will be passed into the overhead controller component right? Schema processing strategy will also be able to be folded into it. Just another diagram here of how I feel:

And yes, our intenral service team needs to chime in on this restructuring, since they subclass the transformer. But maybe this will be more optimal for the future, and internal teams can subclass each individual component in the transformation workflow without worrying about side effects and coupling

dunno, smt like

   interface IModelTransformStrategy {
     shouldTransformElement?(element: Element): Promise<boolean>;
     transformElement?(
       source: Element,
       target: ElementProps
     ): Promise<ElementProps>;
     transformElementAspect?(...): Promise<...>;
     transformRelationship?(...): Promise<...>;
   }

and

  // Today
  const transformer = new MyTransformer(...);
  await transformer.processAll();

  // Proposed
  const transformer = new MyTransformer(...);
  const controller = new IModelTransformController({
    exporter,
    transformer,
    importer,
  });
  await controller.processAll();

[DanRod1999]

Yeah, I think from a naming convention yours makes more sense. Really just depends on how breaking we want the changes to be. I think keeping the top level to be the "IModelTransformer" would be less painful for migration, but idk, also not saying we should dictate our change just based on how easy it is to migrate, just pointing it out. I didn't put too much effort into the name, was more concerned with the roles we are gonna establish for each, and either way we need to introduce a new named class into the infrastructure