[BUG] Annotation table parsing can result in CvParam lists of incorrect length when parsing incorrect building blocks

[kMutagene]

See the code here:

ARCTokenization/src/ARCTokenization/AnnotationTable.fs

Line 202 in 4c93bfc

yield! loop false rest

Everytime this loop parses incorrect building blocks (e.g., when rest is something even if a correct set of building blocks was parsed before) it yields the next parsing results into the same list.

This is problematic for the following reason: This function is used on pre-grouped lists of headers, and expected to return a group of columns of an Annotation table as a list of CvParams.

Example:

Parsing

Parameter[Time]	Unit	Term Source REF (PATO:0000165)	Term Accession Number (PATO:0000165)
5	hour	some TSR	some TAN
2	hour	some TSR	some TAN

returns a list of 2 CvParams, correctly representing the 2 rows of this building block. however, when there is some wrong value that is not
caught by grouping, e.g.

Parameter[Time]	Unit	Term Source REF (PATO:0000165)	Term Accession Number (PATO:0000165)	Hello XD
5	hour	some TSR	some TAN	uhm
2	hour	some TSR	some TAN	yea

the loop will return a list of 4 CvParams, the 2 correct ones, and the incorrect column matching this case:

ARCTokenization/src/ARCTokenization/AnnotationTable.fs

Line 204 in 4c93bfc

| a :: [] ->

I know that we want to have a least-assumption approach, but we can be absolutely certain that the input table has the same amount of cells per row. This bug would lead to transposition of the 2D CvParam list that represents the table columns not working in some cases, because the dimensions are not the same in the inner collections, therefore preventing accessing rows of the table, which represent the process graphs. We need to reflect the knowledge in the output somehow, e.g. by not using yield! here:

ARCTokenization/src/ARCTokenization/AnnotationTable.fs

Lines 188 to 189 in 4c93bfc

	yield! cvPars
	yield! loop false rest

and aggregating the results in the calling function instead.

[kMutagene]

Not relevant anymore since we base our parsing on ARCtrl now (#48)