Transition StructureManager away from being a global

[DanRStevens]

All the uses of Utility<StructureManager> are accessing a global. We should move away from this model and instead have some root game object that holds or owns all game data. For a long time that root object has more or less been MapViewState, though we may start to transition away from that and move more higher level objects into GameState.

As pointed out, one of the restrictions imposed by using global objects is we can't cleanly load a new game without destroying or corrupting the state of an already running game. This means we can't really truly abort and recover from a failed load of a bad saved game file in a way that let's us continue playing an existing game. If all game data is owned by some root object, with no use of globals, then we can potentially have two such root objects during a transition period, and only when the new root object is fully constructed and verified do we destruct the old game object.

---

To make the transition, perhaps we can start to modify access to go through a root game object. The root game object can access the global on their behalf. Eventually the root object can take over ownership and start returning it's own instance.

For other objects, either we query the root object for the StructureManager instance, or the root object can pass an instance in to objects that need it, either through a constructor parameter which is saved in member fields, or a function parameter if it's only needed for some function call.

---

Related:

• Issue Convert StructureCatalogue from static class to regular class #1336
• Issue Convert ProductCatalogue from static class to regular class #1337