front: heavily refactor graou open data import

[Synar]

Graou train schedules parsing logic was spread amongst 5 different files, with functions called at various points of the importing process, without any unifying convention.

In particular, this meant we had to carry a TrainLists parameter on top of the TrainFromJson one in ImportTimetableItemList just for the purpose of storing half-formatted graou train schedules.

Instead :

• move all Graou validation logic that can cause the request to fail to graouApi
• move all Graou parsing/formatting logic in a single new helper file
• fully format Graou train schedules in a single place of ImportTimetableItemConfig, as is done for json, xml and nge files
• drop trainLists
• simplify and document the code as much as possible

I'm not 100% sure about where the validation logic should live, and how strict we want to be with it. For example, should we really reject all train schedules because one uic was missing?

Also close #10159 by querying all chs for each step, as is done in many other places in the front. The fixup commit at the end is an alternative version of the code (which I favor, but does require a new type). Both commits can be extracted to another pr if you wish.

For reviewing, I suggest taking a look at the overall new code flow in ImportTimetableItemConfig as well as parseGraouTrains, and then go commit by commit. I tried to be as atomic as possible (perhaps too much?). Each commit compiles and runs.

Next step could be to write a couple unit tests, at least for the overall Graou import.