Extension packages

[sshin23]

We are starting to see several extension packages emerging (e.g., two-stage models #244 and models with external oracles #243), which is great to see. As the ecosystem grows, it might be worth thinking about how to structure these extensions so that ExaModels itself remains lightweight and maintainable in the long run.

One possible approach could be:

• Separate extension packages from the main ExaModels repo and host them elsewhere. We could follow something similar to the MadNLP approach, where extensions live in a /lib directory, or maintain them as separate repositories.
• Extensions approved/coordinated by ExaModels core developers could be granted a naming convention such as TwoStageExaModels or ExaModelsWithOracle.
• Optionally, we could add breakage checks for extension packages, similar to
  https://github.com/JuliaSmoothOptimizers/NLPModels.jl/blob/main/.github/workflows/breakage.yml

Curious to hear your thoughts.

@michel2323 @andrewrosemberg

[michel2323]

Adding batched model #216 to this.

An NLP oracle, IMO, is part of the basic functionality, and JuMP has this in the base package too.

As for BatchExaModels and TwoStageExaModels, I think they fit very well into the general ExaModels vision of SIMD expressions. Maybe we can get BatchExaModels in a lighter version by also using tags and putting the assembly burden on the solver. TwoStageExaModels is 100 lines of code (and maybe the batched one too). I'm not sure that warrants a separation for maintainability.

To me, the libs in MadNLP are a bit overboard and hard for users to discover. I'd wait and observe.

[andrewrosemberg]

Don't have any strong opinion here (too much of a newcomer), but I agree with @michel2323 regarding:

An NLP oracle, IMO, is part of the basic functionality, and JuMP has this in the base package too.

[sshin23]

Closing -- we will host everything within ExaModels