[Feature] Add setups / OOBE

[matmair]

This PR implements setups as first class citizens. This required for the OOBE and setups in general.

Closes #2284

[matmair]

@SchrodingersGat would you mind taking a look at the syntax for the setup files in this sample file?

Not all functions are done rn; Namely missing is the data action at the end.
There are a few built-in limitations:

• no i18n included - or planned
• only a few specified inputs can be used
• no cross-session state saving - this is only implemented in-session as the whole framework also works without a database (initial setup for example)

[SchrodingersGat]

@matmair I'm away for the weekend, will jump on this first thing next week :)

[SchrodingersGat]

@matmair nice approach here. Given that we are going to start thinking about moving away from server-side rendering and to a frontend framework, should we concentrate more heavily on using the API?

I'm reluctant to introduce more server-rendered forms, if we are going to subsequently have to refactor.. What do you think?

[matmair]

@SchrodingersGat I imagine the switch to be staggered. First all user-frontend, than the admin-frontend. I would like to leave /auth, /admin and /setup in pure django fashion as security with react can sometimes be a bit tricky but if we have some django base sites we can start a session there and embed a ultra-shortlived session token in the browser and use that for auth instead of tokens that work for days and are saved in the browser.

Also the admin stuff does not need to be fancy in my opinion.

[matmair]

Missing:

• finishing action (yaml)
• next setup options (yaml)
• issue event after setup
• SetupRun model
• first startup flag
• settings field (forms)
• built-in setups for config file and use-case