Attempt to fix issues with BuildLimitGroup

[Coronia]

Previously BuildLimitGroup has several issues. E.g. Techno is still buildable when it's reaching the limit but stuck at 50% building progress under certain conditions. This is an attempt to fix some of the issues, which refractor the code of BuildLimitGroup on upgrade to make it work independently from other techno

[github-actions]

Nightly build for this pull request:

• compiled-dll-e2d420baa51a6ee165f0c04f39edb32e6d824454.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[Coronia]

so far no issue has occured in testing, but I'm not sure whether they're all resolved. Would require some more test and review

[TaranDahl]

It would be best to provide an analysis of the errors in the previous implementation and their resulting consequences. Simply put, it should cover "how things were done before", "why the previous approach was wrong", and "how things are done now".
I cannot review the code without context.

[Coronia]

tbh I don't quite understand the idea of original author either, so it's just about fixing these 2 flaws:

• whatever the idea was, it's bad to recalculate and reassign EAX for 3 times in a row. It should be squeezed into 1 calculation if anything
• this function is only supposed to work for Upgrades, while the current implementation make it work for other techno too

So what I'm doing here is basically merging all EAX calculation into one function, and make it only affect Upgrade

Anyway, testing suggested that it can fix the issue of production being interrupted when the factories got changed (e.g. building a new one, EMP a current one etc). However, the 50% production stuck issue still happens sometime. Not sure if I have a way to fix it for now

[Coronia]

more testing suggest that the critical issue of interrupting production when factory status changed is resolved, while there're still edge cases to make the production stuck at 50%. This is only a visual bug that won't actually bypass the limit, and can't be resolved easily as of now

given this situation, maybe we should review and merge it first, and return to the above minor issue later on