feat(enhancement): Add support for a new, nested attribute format

[tibetiroka]

Feature: This PR implements the feature request detailed and discussed in issue #9025

Feature Details

This PR is the first to implement the feature mentioned above. It only adds basic engine support for the data format; enabling the new attributes will be part of a separate PR. This one is big enough already.

What this PR does:

• Internally stores the relevant attributes in the new format
• Provides two-way mappings between the two formats
• Loads attributes in the new format
• Saves attributes in the new format

What this PR doesn't do:

• Add any new attributes
• Change the way attributes are queried or handled by other classes Some queries have been changed to the new format
• Rename any existing attribute

Currently, this PR just maps the attributes to their old string equivalents to provide the best compatibility with existing code. It also contains some mechanics that will be enabled / used by future PRs when internal support for the new attribute format is added. In the long term, I'd like to move away from flattened attribute names entirely (for the relevant attributes).

Usage Examples

Some new data stuff that could be done using the new format (with future functionality):

• Wanderer thruster that only cools your ship while thrusting
• Cloak that disrupts shields and scrambles weapons (no need for cloak types)
• An active cooler that pushes your ship around (because its fan is so strong)
• Hull repair bots that disrupt your shields only while repairing

This PR gives us many new possibilities without introducing new attribute "keywords".

Have a look at #9025 for more ideas.

This feature is most useful for outfit definitions, but it does also affect save files slightly. Here's a comparison of an Arfecta's attributes from a save file:

Before

	attributes
		category "Medium Warship"
		cost 90000000
		mass 1325
		bunks 46
		"cargo space" 64
		"cloaking fuel" -0.2
		drag 11.25
		"energy capacity" 10000
		"energy generation" 200
		"engine capacity" 220
		"fuel capacity" 1200
		"heat dissipation" 0.54
		"heat generation" 10
		hull 80000
		"hull energy" 5
		"hull repair rate" 5
		"outfit space" 640
		"required crew" 36
		"reverse thrust" 99
		"reverse thrusting energy" 4.9
		"reverse thrusting heat" 6.9
		"shield energy" 32
		"shield generation" 32
		shields 98000
		"turret mounts" 5
		"weapon capacity" 390

After

attributes
		category "Medium Warship"
		cost 90000000
		mass 1325
		bunks 46
		"cargo space" 64
		drag 11.25
		"energy generation" 200
		"engine capacity" 220
		"heat dissipation" 0.54
		"heat generation" 10
		"outfit space" 640
		"required crew" 36
		"turret mounts" 5
		"weapon capacity" 390
		"shield generation" 32
			energy 32
		"hull repair" 5
			energy 5
		"reverse thrust" 99
			energy 4.9
			heat 6.9
		cloak 0
			fuel -0.2
		capacity
			shields 98000
			hull 80000
			energy 10000
			fuel 1200

Testing Done

• Mapping between flattened and hierarchical attributes
• Attribute loading
• Attribute saving

Automated Tests Added

300-ish lines of unit tests to cover most of the new stuff. I couldn't test attribute saving this way, though. (#8725 would make those tests possible.) Attribute saving is now also tested.

Performance Impact

I'll test it later.

[petervdmeer]

I feel that this is better placed in AttributeCategory, and using a map (similar to oldtoNew below) is likely more maintainable when we add new categories.

[tibetiroka]

AttributeCategory is an enum, so if I put it there, it would be a global. I could move it to AttributeAccessor, if that would be better.

[petervdmeer]

This PR is the first to implement the feature mentioned above. It only adds basic engine support for the data format; enabling the new attributes will be part of a separate PR. This one is big enough already.

You might want to consider splitting this PR into separate parts:

• Implementing the new data-format (on top of the old engine-code)
• Implementing engine support for attribute categories and effect-types (regardless of the data-format used).

I expect the data-format and the engine-support not to match 1:1 in the end; the over time damage which I mentioned will probably keep it's own keywords (in the 2 layer-keywords-format from #9025), while in the engine they just get mapped to their basic types. (the corrosion, leak, etc keywords are just very nice as syntax for content-creators, while in-engine they might be better of as variants of hull and fuel).

Splitting is not required for me, and if you do decide to split, then I also don't have a preference for which part is done first. It's just that this PR as-is is quite big.

[tibetiroka]

You might want to consider splitting this PR into separate parts:
Implementing the new data-format (on top of the old engine-code)
Implementing engine support for attribute categories and effect-types (regardless of the data-format used).

That's pretty much what happened. Yes, the accessors used in the engine changed, but that's the extent of the refactors done here. No new attributes get engine support, only parsing support.

[petervdmeer]

We discussed the syntax for the data-files quite a bit on Discord today. Could you already prepare the PR for the Wiki to describing the data-format already as it will be used? Then we can handle the full set of data-format changes ahead of the implementation.

And does it make sense to also have an "idle" section for the "energy generation" and "heat generation" attributes?
And I noticed in the example that cloak has a fuel negative number, does that mean that cloaking will generate fuel?