Replace manually written data classes with ones generated by OpenAPI

[snkaupe]

The status page web frontend currently uses a set of handwritten classes to handle the data returned from the status API server. We should replace these with the classes and REST client generated from the status server's OpenAPI specification. This will make future updates to the API server and frontend easier.

[snkaupe]

Work on this issue has turned out to be slower than expected, mostly due to my initial approach on how to integrate the API server client generated by OpenAPI turning out to have been more complicated and problematic than initially expected (an additional layer between data model and frontend that would have lazily constructed object trees using the string IDs used to reference other entities in the OpenAPI data model). I've since switched over to a much simpler strategy for holding the data (stuff it into maps and query once needed).

[snkaupe]

The actual work has finally been finished, though some testing is still supposed to be done. Testing requires me to perform an OS upgrade beforehand, which I'll get to immediately. Once done, the testing can start, any outstanding issues can be fixed and this ticket can finally be closed.

[snkaupe]

Testing has concluded, but @joshuai96 recently added some changes to the status API server that would probably allow us to simplify the loading process (impacts with severity are now included with the incidents, too, not just the components). This issue will remain open until either these changes have been performed or it has been ultimately decided that we do not have the time for this. Determination of this should not take overly long.

[snkaupe]

The changes have finally been merged. The code will currently not be rewritten to make use of the new fields in the API server's responses.