Improves the harvester AI.

[Rampastring]

Closes #201 , Closes #203

This pull request implements 2 features to improve the harvester AI:

• The harvester's refinery-seeking algorithm now considers both free refineries and occupied refineries when figuring out which refinery to unload at. If the closest occupied refinery is much closer to the harvester than the closest free refinery, the harvester queues for the occipied refinery instead of going for the free refinery.

• In vanilla TS, harvesters always go for the northernmost tiberium patch if there is one. This means that on some starting locations, harvesters tend to move just further and further away from your refinery as they harvest, because on each cycle they just go further and further to the north. On other starting locations this behaviour, on the other hand, is usually beneficial (if your refineries are to the north of a tiberium field). This creates a bad imbalance for most maps. Instead of having fixed preferred directions for the tiberium-seeking algorithm, harvesters now pick the most valuable patch that's also closest to their last refinery. This keeps the resources flowing faster, keeps your harvesters safe and levels the playing field between different starting locations.

These features are also explained in the following issues:

#201
#203

Earlier I also had a fix for #202 but it was noted to cause desync errors in multplayer, so a better solution for that will have to be found.

Rules.ini settings

To allow customizing the behaviour of these features, this PR adds the following Rules.ini key, section [General]:

; When looking for refineries, harvesters will prefer a distant free
; refinery over a closer occupied refinery if the refineries' distance
; difference in cells is less than this.
MaxFreeRefineryDistanceBias=<int> ; defaults to 16

[github-actions]

This comment is automaticly generated by Nightly.link and allows non-registered users to get download the artifacts for this pull request.

These links are also updated when the pull request is pushed to.

• vinifera-preview-95b180c.zip
• vinifera-preview-95b180c-ts_client.zip

[CCHyper]

Before I perform a full review;

Can this PR be rebased to the upstream develop branch, also can a pass be made on the implementation approach, where some static functions can be moved to the extension classes for a cleaner implementation (for example, footext_functions.h is outdated here).

Thanks.