Fixed the domain type in CvTeam::getTypicalUnitValue.

CvTeam::getTypicalUnitValue wasn't passing eDomain to CvPlayer.
This means the domain type was basically being ignored.
Made some change to how city names are choosen.

When a new city is created, and a name is being chosen from the
civilization's city name list, the search will now skip a name of names
corresponding to the number of cities the player has already founded.
This means that if a player renames a city that they have founded, the
game won't immediately suggest the same previous name for the next city.

Note 1: this only applies to names taken from the civilization city names
list. It does not apply to names on the player-specific city list which
may be used by some mods.
Note 2: previously used names will again
be suggested if the civ's city name list is otherwise exhausted.

Also, if the civilization's list of city names is exhausted, then the
game will suggest a _random_ name from a random civ; rather than the
first available city name from a random civ.
Made some adjustments to the AI's decision making for chopping forests.

The yield produced from chopping is no longer counted in the evaluation
of improvements. This allows us to decide whether or not the new
improvement would be better regardless of potential immediate benefits.

The bChop checks will now be bypassed if the city is building a process.

The value of chopping is now scaled up a bit if the player hasn't yet
reached the target number of cities for the map size.
Made some AI changes in CvCityAI::AI_updateSpecialYieldMultiplier.

The adjustments associated with workboats, workers, and settlers are now
all the same. The effect of building a workboat is now less significant.

GetBetterUnit and EconomyFocus now result in a boost to commerce value.
The 'production' strategy now boosts production and lowers commerce.

Reduced the magnitude of the commerce value reduction when at war; and
made it more conditional. Also, increased the productivity value boost
for war when using dagger or crush.
Short-circuited some unneccessary calls to CvCitAI::AI_commerceWeight.

Added conditions to bypass some calls to AI_commerceWeight when it would
only have been used to multiply zero.

Also, fixed an original BtS bug in CvPlayerAI::AI_techValue which caused
all new processes to be identified as being "good".
CvPlot::getYieldWithBuild now counts 'extra yield'. (eg. from financial)

It still does not count the bonus yield from golden-ages.
Fixed a misuse of getGoldPerTurn in CvPlayerAI::AI_commerceWeight.

CvPlayer::getGoldPerTurn refers only to gold from trade deals. The value
that AI_commerceWeight really wanted was calculateGoldRate.
(Unfortunately, the corrected version is slightly slower. - But at least
it makes sense!)
Added function AI_getAvailableIncome. Replaced old code for consistency.

AI_updateAvailableIncome calculates and caches an estimate of the total
gold-per-turn revenue the player could achieve if they used 100% gold on
the commerce slider. This function is called once per turn, and the
result is accessed with AI_getAvailableIncome.

AI_getAvailableIncome is now used to replace some previous income
estimates which typically worked by simply adding
getCommerceRate(COMMERCE_SCIENCE) + getCommerceRate(COMMERCE_GOLD) + std::max(0, goldPerTurn())
The old calculation was flawed in that it failed to correctly handle
espionage or culture on the commerce slider.
Corrected the position of the new era screen.

Apparently 'centerX' only works if the screen is size 1024; and so my
previous attempt to center the new era screen was actually putting it
left of center.
Adjusted the conditions and effect of bChop in AI_updateBestBuild

bChop will now be set true for pretty much everything when the civ has
less than the target number of cities. Also, the priority of best build
is now increased when it produces chopping yield when bChop is true.
Made some stop-gap adjustments to the AI's improvement yield evaluations

There are some serious flaws in the AI's evaluation of yield when
choosing which improvements to build. In particular, the value of food
does not scale when the value of jobs that could be worked with more
food; and the value of yield in general is inconistent with the way the
AI chooses which plots to work.. And so sometimes the AI will replace
good improvements with new ones which won't be worked; or replace high
food improvements with other improvements which won't have enough food
to be worked...

I don't address the core of these problem in this minor update, but I
have made a few changes with might help. In particular, I've decreased
the multiplier used for production, so that production doesn't end up
being worth signficantly more than food.
Added CvCityAI::AI_isGoodPlot, and used this to removed duplicated code.

The bulk of AI_getGoodTileCount and AI_countWorkedPoorTiles has been
replaced by calls to CvCityAI::AI_isGoodPlot.

Note: the 'good plot' check in AI_getYieldMultipliers hasn't yet been
replaced; because that function is about to be completely restructured.
Renamed AI_getGoodTileCount and AI_countWorkedPoorTiles

CvCityAI::AI_getGoodTileCount renamed to AI_countGoodPlots.
CvCityAI::AI_countWorkedPoorTiles renamed to AI_countWorkedPoorPlots.

(The terminology of "plots" and "count" is more consistent with the rest
of the code.)
AI_getYieldWithBuild now counts yield from existing improvements.

Previously AI_getYieldWithBuild would only count yield from improvements
created by the build itself. And so, for example, if you were building a
railroad on a mine, the functino would count the natural yield of the
plot, and the extra yield from the railroad, but not from the mine
itself.

This is now corrected.
Fixed a possible crash in AI_warCommitmentCost and changed overseas cost

AI_warCommitmentCost would previously divide by zero when evaluating an
overseas war in which neither was able to build any boats. This has been
corrected.

Also, the flat adjustement of 5/4 for total war overseas has been
replaced by a factor which depends on the relative strength of the
ground forces.
The CvCity::findXRank functions now update rank for all cities at once.

This includes findPopulationRank, findBaseYieldRateRank,
findYieldRateRank, and findCommerceRateRank.

In the original BtS code, these functions would compare the current city
to every other city to find its rank, and thus only set the cache for
the city being queried. The new code gathers all of the city data, sorts
it, and set the rank cache for every city in one pass.
Rewrote CvCityAI::AI_getYieldMultipliers; fixed a food scaling problem.

The new version of AI_getYieldMultipliers is similar to old, but it is a
bit simplier, it includes a few flavour adjustments; but most
importantly, the food value multiplier now scales up as other yields
become more valued. This is to avoid the problem where production can
end up being worth more than the food that is necessary to work the
production.

Some other related CvCityAI functions have been tweaked to be consistent
with the new version of AI_getYieldMultipliers.
Added 'high food' check to bonuses added by normalizeAddFoodBonuses

Although existing land food bonuses which only net 3 food are only
counted for 2 points; bonuses which were added to boost the total score
were previously not subject to this test... This means it was still
possible to have a low food capital city in some rare situations.

This is now fixed.
Tweaked the sort order in the revised AI_findXRank functions.

Changed the sorting from (score, cityID) in decending order, to
(-score, cityID) in ascending order; the affect of this change is that
lower cityIDs will be ranked higher, which is consistent with the
original code, and is more intuitive in certain in-game situations.
AI_assignWorkingPlots now clears specialists in some situations.

Specialists will once again be cleared and reassigned for automated city
with forced specialists. Without this, the loose rule that all
specialists should be the same type as the forced specialist breaks
down.