Cleaner player progression tracking

[jakmeier]

This issue is related to #13

Current Situation

An enum called StoryState tracks the story/tutorial progress of each player. This enum is shared across modules but what each story state means exactly is not captured at a single location.

To go between different story states, the game-master is programmed to recognize the necessary conditions, such as when a new specific building has been placed. The frontend often has to recognize it must be updated, too. The code for this is currently all over the place, pretty much hand-crafted for each state-transition.

Goals

We need a cleaner design to handle the definition of what each state means and what happens on a transition between states.
It would be great to have a central specification for this inside the shared library. The frontend and the backend could then execute their separate state machines according to the specifications and we could even generate documentation for the wiki.

[jakmeier]

Good progress has been made over the weekend.
An FSM for what transitions are possible and what happens on them is written down in Rust right here: story_transitions.rs
This serves as the ground truth of what we the story progression looks like. It allows to keep using the enum StoryState. A new (compley) enum called StoryAction is now also used. It makes the meaning of what happens on story tansitions centrally defined, rather than defined ad-hoc in each file that contains code for executing such actions.

From the specification, it is now possible to generate a graph like this:
(Link to file in repo)