Resources other than metal/energy

Bill of materials to be done before starting this ticket:
* #939

---

Collection of misc thoughts that I had written down from some ancient discord discussion. This is all from the **game dev perspective** so doesn't address engine implementation details (including whether this involves ECS or not).

### Context
* a game **might simply want to have 3+** resources.
* a game that only needs 2 is **still made harder to develop** and work with if they are supposed to be gold/wood, or minerals/gas, etc since even if you expose them as such to the player, the **engine interfaces still call them metal/energy**.
* there are the vague plans to implement ECS for resources at some point so that may be a good opportunity to touch the wider design. It doesn't rely on it though and both can be done independently.

### How many?
* of course **ideally there would be no limit**, but there may be perf and design implications.
* off the top of my head, the **most resources I've seen used in an RTS is 6**. One is the mineralz mod for SC2 which maybe doesn't really count (but that kind of modding is the lifeblood of projects around here!), but also Cossacks was a serious commercial game with 6. HoMM has 7, it's not an RTS, but close and it sounds like the kind of game a crazy modder could want to make an RTS spin-off of. There may also be more resources in other real game examples that I don't personally know. In that vein **I think 8 would be a good limit**, it leaves some room for creativity while being nice and round.
* the original ECS proposal said 4, which feels a bit harsh and existing-game-centric (in that it would support existing games but not much above), though **if the overhead is significant** it would probably be acceptable. Hard to tell beforehand.
* perhaps a mixed hard/soft limit? A more lenient hard limit (say 8 or 32 or **whatever is implementationally maximal** without increasing passive overhead) that will probably **allow a game to make tradeoffs** if it wants to, and soft limit that you specify in a modrule (e.g. "this game has 2 resources") that **prevents the engine needlessly processing** the extras.

### Lua API

The basic and obvious approach would be to **make interfaces refer to resources via a numerical index**, grouped into a table where appropriate, with **names read from a modrule and exposed as a `Game` subtable**:
```diff
modrules.lua
+ resources = { "Gold", "Vespene", "Requisition" }
+ -- Game.Resource.Vespene = 2 and Game.Resource[2] = "Vespene", etc

unit.lua
- metalCost = 426
- energyCost = 1826381
+ cost = { [Game.Resource.Metal ] = 426, -- perhaps just [Metal] if the fields were exposed as globals
+ [Game.Resource.Energy] = 1826381, }

unit.lua, different game
+ cost = {
+ [Game.Resource.Food] = 50,
+ [Game.Resource.Wood] = 25,
+ [Game.Resource.Gold] = 175,
+ }

gadget.lua
- Spring.AddTeamResource(teamID, "m", +200)
+ Spring.AddTeamResource(teamID, Game.Resource.Minerals, +200)

- local bloodUpkeep = UnitDefNames.factory.energyUpkeep -- using energy as blood
+ local bloodUpkeep = UnitDefNames.factory.upkeep[Game.Resource.Blood]
```

### Misc thoughts
* ideally all resources would be **fungible**. See #939
* the engine actually assigns colours to resources. This can be seen via `/resbar` and `/sharedialog` where metal and energy are consistently colour-coded as white and yellow respectively. Perhaps further resources can be assigned arbitrary colours though since this sounds quite unimportant.
* the above two interfaces might also look bad if you have to cram like 8 different sliders/bars into them. Again though, since these are crude "early dev" interfaces perhaps they can just display the first two resources.
* a game can in theory already do the Lua API changes on its own, under the hard limit of two resources, by applying enough wrapping and field copying. I don't think GF would be too happy if I made ZK a guinea pig this way but a game can be forward-compatible with the suggestion above to some extent (but I expect the design to change with critique, and also such change would make it less compatible with other Spring/Recoil games if done without engine backing).