Under-the-hood improvement: separate data model from output model

[croesnick]

Situation

Currently, there is just one model used throughout the whole extension: the CsvEntry.
This model, however, is tightly coupled with the storage format.

Problem

One model does not fit all. For instance, the location information is stored as a string in this model. But this is a choice only reasonable for the csv export, but not at other places in the program, where having explicit access to, say, the stating line would be needed.

Solution

Introduce a program internal data model.
Also: Consider applying the Repository Pattern to reduce the coupling to the explicit Csv output format. This would also make switching to future output formats (json? yaml?) easier.