[Design] Discussing the API Expose for the Pluggable Optimization Pass #465

Now that since we already have the pluggable optimization pass, the next step is to discuss what is the intended "proper way" to use it.

Things I can think of:

For different usages, where should the developers place their code?

I can think of 2 example usages of this feature:

1. ASAPPlanner developers, in optimization algorithm design, may want to maintain some other optimization passes besides the major one within the repo for a long-term development. This requires some places in the repo to hold such separate passes.
2. ASAPPlanner users may only want to leverage the ASAPPlanner's DAG language, but implement their own optimization passes. For such users, they should implement their optimization outside of the planner repo. Although currently the DAG language themselves are public to users, some useful helper functions, like lift and relational_join_guarantee in ASAPPlanner/crates/asap-aware-mapping/src/replacement.rs, are still private, which is not ideal.

API publicity related to this issue

According to item 2 proposed in the last section, ideally we should expose some helper functions to more "gray-box" lib users.
Should the API publicity for these users be of the same level of the black-box users (who only want to use the end-to-end optimization function)