Theoretical improvements to workerAutomation performance

[Ambeco]

getImprovementRanking used to double-calculate improvements after removing features.

Before, when #getImprovementRanking was calculating the score of removing something, it would then calculate all possible improvements on top of that.  So when #chooseImprovement was scoring TradingPost, Camp, Fort, and RemoveJungle, then while scoring removeJungle it would recalculate TradingPost, Camp, and Fort.

Now, #chooseImprovement passes a list of improvements it knows of to getImprovementRanking, so that when scoring removeJungle, it no longer recalculates TradingPost, Camp, and Fort, though still calculates any new improvements.

tryHeadTowardsUndevelopedCity stops when it finds a close city with work to do

tileHasWorkToDo is expensive. It used to call tileHasWorkToDo on all cities, and then sort.  Now it sorts, and then calls tileHasWorkToDo until one returns true.

chooseImprovement now only ranks improvements once and caches results

chooseImprovement stores priority in RankedImprovements, and does the rest of the calculations with those.
To make this work I also had to ensure that tile.improvement was in the list, even if this unit can't build it, but when the unit CAN build it, the priority is only calculated once and shared.

This also forces all improvements to be in ruleSet.tileImprovements, but the only way that could have failed was if currentTile.improvementInProgress or currentTile.improvement were not in that map, which can only occur for loading an invalid save anyway, so that should be fine.

Performance

Annoyingly, when I (badly) measured the performance, it was statistically insignificant. :(