feat: decouple memote history from the git history

[mihai-sysbio]

Checklist

• There are no similar issues or pull requests for this yet.

Is your feature related to a problem? Please describe it.

I want to be able to run memote on a series of model versions that I get to choose.

Describe the solution you would like.

For new users, I would like to show a history report only on the major releases of a model (potentially truncated to latest relevant ones).
For the community, I would like to show a history report of the major and minor releases of a model.
For the developers, I would like to show a history report of the last X releases including their latest changes on eg their new branch.
Another scenario is when a website (eg MetabolicAtlas) or standard (eg standard-GEM) would want to run the history report for a model for a few selected versions.

In other words, as a user of memote, I would like to be able to decide what the history report runs on. Morever, the more control I can be given over the report (ie format) the easier I can plug that into eg own databases or PR comments.

Describe alternatives you considered

The only alternative I found is either to run memote individually and piece together the history myself.
A git interval was suggested, but that only takes care of a start and end hash, without affecting the granularity.

Additional context

As described in #498, the history report can easily become overwhelming/noisy. Another issue it could trigger is #389.

[Midnighter]

Great, thank you for the description @mihai-sysbio. Could you say something about how you would expect to provide this information? It seems a bit intricate just for command line arguments so maybe a config file? A file is less flexible, though. I'm curious what your thoughts are.

[mihai-sysbio]

Could you say something about how you would expect to provide this information? It seems a bit intricate just for command line arguments so maybe a config file?

What I am imagining is either a comma-separated list of commit hashes or tags, or a file with one such git reference per line (much more simple than a proper config).