Specify CSV input / output format for fmusim

[t-sommer]

fixes #441
[skip ci]

[chrbertsch]

FMI Design web meeting:

• Christian: Consistent with https://github.com/modelica/fmi-standard.org/blob/main/CONTRIBUTING.md#importing-tools ?
• Pierre: it should be at one place in the end, could also be a layered standard.
• Andreas: Define special values such as "infinity"
• Torsten: String arrays currently not defined, one could not use standard parsers otherwise
• Pierre: let's first concentrate on the 80% solution.

[KarlWernersson]

Wouldn't it be allot simpler to scalarize the array for the result file, the reason to use csv is that it is simple, this makes it more complex,
if we want a more complex struct we should we not design our own format and call it something else? Could still be similar to csv?

[t-sommer]

If we scalarize the arrays, we introduce new column names that don't exist in the XML or might even collide with existing variable names. You also re-introduce all the problems arrays in FMI 3.0 have solved like 0 vs 1-based indexing, missing elements, redundancy, etc.

[chrbertsch]

FMI Design Webmeeting:
Karl: Is this still CSV? Will the break when opening in some tool, e.g. in Excel?
Klaus: There is not standardization for CSV
Karl: Should we call this differently? e.g. ".fmicsv"
Otto: Tools should not break, just treat the content as "text"
Klaus: Opening any CSV in Excel can be problematic anyway.
Pierre: Alternatate way: Duplicating columns, "repeating the column header": Benefit: support for string and binary arrays. But this brings other problems,
Torsten: What happens if size changes?
Pierre: using CSV in principle enables processing it in different tools. Better than only text format and simple.
Masoud: why not expanding it? A[1],
Pierre: introduces name clashes A, A[1] could be both present. Has same problem as repeated names. I would stay with the current approach
Torsten: There can be missing elements.
Torsten: it is the same as in XML.
Klaus, Torsten: it is a string and has to be parsed.
Pierre: Can be split also in Excel
Karl: I would be in favour of repeating the array name. Or using another format than CSV
Kaska: We could handle variable size arrays in the way with repeated array names for the maximum size
Pierre: but not for the logging
Klaus: it is good that we chose commas as separators
Christian W: We discuss two things: the syntax of the CSV file ( http://format.gbv.de/csv/rfc4180), how do we (FMI Group) interpret these columns.
Pierre, Torsten: we are compliant with this rfc.

Christian: Should we include the definition of events with duplicating a time?