Consider merging into TulipaEnergyModel

[abelsiqueira]

@suvayu raised the point that it might be better to merge this package into TulipaEnergyModel. One immediate benefit would be removing the semi-circular dependency TEM -> TB -> TEM/test that we discussed, @datejada.
The main issue is that the development of both tools is merged, so fast iteration of TB is no longer possible. As such, I would recommend at least getting to a point where the main API is stable enough to be recommended to end-users.
On the other hand, keeping them separate would keep TEM lighter for users who don't depend on TB. This is not a big problem for now, because TB is not too heavy, but it would still require MetaGraphsNext and DataFrames.

[datejada]

@suvayu @abelsiqueira thanks both 🥲 I think it is not a bad idea to include TB into TEM. TB is lightweight in code but heavy in dependencies, so I think it is worth considering the balance before making a decision. Another thing is that TB is still incomplete; it needs the multi-year investment feature. So, I guess we can revisit this idea after the multi-year dev for TB and then decide.

@gnawin, what do you think?

[gnawin]

Agreed with all of you.

My main ideas are:

1. the multi-year dev for TB is not yet incomplete, although I am not so up to date on the technical details on how these two would merge. I think if we (possibly me) can spare some time, we can improve that part and make a decision.
2. I'd like to avoid the situation that after merging, TEM becomes more friendly to both developers (for the testing) and users, but becomes too slow in the meantime (I'm thinking of the DEMOSES case where Tulipa is called again and again). But based on your information, it's only two more dependencies, so maybe that's just fine.