feat: add helper function for the MTD CV entries

[jorainer]

• Add a helper function to create the CV entries for the MTD element of an mzTab-M (issue Create low level functions for mzTab-M export #35).

[jorainer]

This re-uses your code from MsIO @philouail . what I would like to have is something like:

mtb_skeleton(...) where the user can specify entries/values for the MTB section and it returns a two column matrix - that could then be further expanded (additional elements added manually) and then written into the mzTab-M file.

Internally, the mtb_skeleton() function will ideally call other helper functions that format/check the input. This PR adds the first one, .cv() that builds the CV ontology definition.

[jorainer]

Essentially, please check only the MTD.R (and related unit test) file - the rest is re-running devtools::document() on the package.

And to explain, maybe check the @examples of the mtd_skeleton() function (from line 182 on). The idea is to have a function that creates a skeleton metadata section and the user/software developer completes and extends it.

Also, what is currently missing is the sample and ms run information. I will work now on a function to extract that from file names/sample annotations data.frame.

[jorainer]

@philouail @gpatoine , quick update: I have now also added a mtd_ms_run() function to define the ms_run fields of the MTD section. That one should be completely covered, with all mandatory and optional fields. I will next work on the assay, sample and study variable parts.

As always, any feedback is welcome, in particular if you spot something that you don't agree. Better to discuss early on than first implementing all and then changing :)

I also added a general MTD documentation to describe there all the individual functions. For now (and to keep development and testing simple) I split the functionality into separate small functions. We can then maybe at the end have one main function that calls all the individual ones. But also, for now, this code is more for the developer and not the user - so that we can e.g. implement export code easily for QFeatures or SummarizedExperiment and XcmsExperiment.

[philouail]

ok very minor comments
This was so much work thanks a lot. the documentation is amazing.
I wonder if this is not a bit to much for one single file. but we can discuss repo organization another time with everyone.

[philouail]

"categarized" typo

[philouail]

mmm i know this is somewhat a bad idea, but should we control the version ? as writer maybe we should. especially if the specification change and therefore the code change, it would be a way to keep integrity ? I know it's weird but just wanted to discuss it