Add simple energy balance info without dictionaries

[0HyperCube]

Brief Description of What This PR Does

Create an EnergyBalanceInfoSimple class that doesn't record the consumption and production. This is used for the auto evo since it doesn't require the consumption and production information.

Also add an EnergyBalanceInfoFull class that inherits from EnergyBalanceInfoSimple but with the dictionaries for consumption and production. This is used for the editor display.

Since there are virtual methods now, this will likely be detrimental to performance. However I wasn't able to test the significance of this compared to removing the dictionary allocations for auto-evo since there doesn't see to be a great way to benchmark auto-evo.

Related Issues
Closes #5426

Progress Checklist

Note: before starting this checklist the PR should be marked as non-draft.

• PR author has checked that this PR works as intended and doesn't
  break existing features:
  https://wiki.revolutionarygamesstudio.com/wiki/Testing_Checklist
  (this is important as to not waste the time of Thrive team
  members reviewing this PR)
• Initial code review passed (this and further items should not be checked by the PR author)
• Functionality is confirmed working by another person (see above checklist link)
• Final code review is passed and code conforms to the
  styleguide.

Before merging all CI jobs should finish on this PR without errors, if
there are automatically detected style issues they should be fixed by
the PR author. Merging must follow our
styleguide.

[revolutionary-bot]

The lead programmer for Thrive is currently on vacation until 2025-01-07. Until then other programmers will try to make pull request reviews, but please be patient if your PR is not getting reviewed.

PRs may be merged after multiple programmers have approved the changes (especially making sure to ensure style guide conformance and gameplay testing are good). If there are no active experienced programmers who can perform merges, PRs may need to wait until the lead programmer is back to be merged.

[hhyyrylainen]

This is already a very good start, but I kind of want the architecture split to go a bit deeper even if that means a bit of code duplication (but on balance removes the virtual methods).

[hhyyrylainen]

Is there a reason why this was closed?

[0HyperCube]

@hhyyrylainen the changes requested around avoiding the virtual methods would involve rewriting the PR. I'm happy to do this when I have some free time.

[hhyyrylainen]

Yeah, a bit of refactoring would be needed, but I thought it wouldn't require rewriting all of the PR so I was wondering about the close.

I'm happy to do this when I have some free time.

Totally fine. This isn't a super high priority thing so you can help out again once you have time.

[0HyperCube]

@hhyyrylainen I believe that I have refactored this PR as desired?

[hhyyrylainen]

Overall it's a lot better now but some of the naming stuff doesn't fully make sense to me and the doc comments didn't make it clear why such a name was chosen.