csv_export only tested within gui

[yngve-sk]

If the any underlying logic of csv export, as done in ert/workflows/jobs/internal-gui/scripts/csv_export.py:run fails or throws an error, it will cause the gui test for csv export (test_csv_export.py) to just hang, waiting for some qt thing to never appear. Since it mostly goes into storage, it is "vulnerable" to changes in storage leading to just another hanging gui test, without it being obvious why. This is also an unfortunate mixing of business logic which is "backend" into the frontend, ideally (personal opinion) there is more of a separation

Proposed solutions (pick one, which one is the better is up for discussion)

1. Test the logic of csv export (contents of ert/workflows/jobs/internal-gui/scripts/csv_export.py:run) separately, the test can just do the same as the current one: Run poly and export with the same settings as is default in the GUI.
2. Make the errors from "gui plugins" surface more explicitly so the gui tests don't hang forever
3. Make the gui test somehow not hang and to stop if an error surfaces from the csv export logic