Add state handling solution

[LittleHelicase]

Probably provider.

Ready for microfrontends (?!)]

General idea:

• Firestore backend for non assets / fast changing data (allows for collaborative editing)
• App talks to provider, does not care for firestore or not (also important for separating mobile / web / desktop support)
• provider is split up into microfrontend packages and main combines them and connects the dot

[hastebrot]

For a broader discussion I also want to mention traditional approaches, even when we won't use them:

1. Communication with backend via restful websevice. The backend uses a relational database for persistence.
2. Update frontend widgets using event listeners, e.g. ChangeNotifier in case of Flutter.
3. Update game state to redraw the canvas, e.g. components in case of Flame.

In the moment I see that provider will help us with 1 (the restful webservice replaced with firestore) and 2 (the ChangeNotifier augmented using provider), but it will not help us much with 3, since the state is only propagated to the game widget.

[LittleHelicase]

I would not say, that we will not use "traditional approaches" per se

1. Who knows if we need some traditional backend in the end.
2. Provider uses ChangeNotifier but also gives you an organized way of setting it up.
3. Good point. I would not see provider as a storage for the in-game state