feat: setExchangeBounds new function to set exchange bounds for given mets

[JonathanRob]

Main improvements in this PR:

New function setMetExchange allows users to set the exchange flux bounds for a given list of metabolites. This should be helpful for specifying e.g., media conditions, or other nutrient uptake/export fluxes.

I hereby confirm that I have:

• Tested my code on my own machine
• Followed the development guidelines.
• Selected devel as a target branch

[haowang-bioinfo]

two quick comments:

1. how about rename to setExchangeMets.
2. now RAVEN starts to include subheadings Inputs: and Outputs:, please add them to the header

[JonathanRob]

@Hao-Chalmers I added the subheadings to the function header.

As for the suggested name change to setExchangeMets, I don't mind changing it to this, but I'm not sure it's as accurate. setExchangeMets sounds to me as if I'm defining which metabolites are exchange metabolites, which is a property of the S-matrix. I named it setMetExchange because I am setting the metabolite exchange rate for a given set of metabolites.

I'm actually a bit uncertain as to which name I prefer, and am open to other suggestions.

[haowang-bioinfo]

@JonathanRob how about setExchangeFluxs or setExchangeRates .

[edkerk]

@Hao-Chalmers @JonathanRob what about setExchangeBounds?

[haowang-bioinfo]

setExchangeBounds seems more fit

[JonathanRob]

I agree, setExchangeBounds seems to be the most appropriate.

[haowang-bioinfo]

@JonathanRob is it feasible to have an associated test function to evaluate/test the performance of this function?

@edkerk it might be good to include a test folder allowing the addition of testing functions in the future?

[JonathanRob]

@Hao-Chalmers Of course, I can certainly arrange such a function if there is a place for it.

[edkerk]

is it feasible to have an associated test function to evaluate/test the performance of this function?

@Hao-Chalmers Do you mean tests that check that the various RAVEN functions are working as intended, as quality control for future development? This would be really good, although it is probably quite time intensive. I would then prioritize #184 instead.