refactor(backend): switch to pydantic from marshmallow

[mikonse]

As a proposal for a longer refactoring with the end goal of moving from flask + marshmallow to fastapi + pydantic this would be the first step to refactor the API datamodels from marshmallow to pydantic.

The idea behind this switch in framework / underlying library for me is that pydantic + fastapi produces a much nicer editor experience because you can rely on type checker and editor autocompletion support for the schemas and have a lower chance of getting errors into the API controller code due to typos / type mismatches.

Additionally the currently somewhat manually documented API in the kitchenowl docs could be replaced by the automatic openapi export that fastapi supports with an inline swagger API browser.

@TomBursch I'm very much open to discussion about this. If this is something you would be interested to see I'm happy to drive this forward and open pulls along the way. I'll try to keep this as multi stage refactors so we would have multiple sets of changes instead of one big change to fastapi.

[TomBursch]

I'm not sure about the FastAPI migration, but Pydantic instead of Marshmallow is a good change

[mikonse]

Sounds good, I'll have a look when I get time to rebase this pydantic branch onto the most recent changes and test it on my personal deployment 👍

Regarding the fastapi changes, I've also had a look at that and while I think in the longterm it would provide a better development experience than flask it is by far not as easy a drop in replacement as marshmallow -> pydantic due to the additional number of flask based plugins which this project uses.
But maybe I'll keep playing around and give you a ping if I've found a way to migrate without to huge a churn and a better gauge of what the main benefits would be.