Fixed a bug in getLiberationPlayer

I'd made a typo which caused the function never recognise which is the
original owner of the city.
Minor change for C++11 compliance.

In newer compilers, the template arguments in std::make_pair are a bit
different to allow for perfect forwarding. So I'm just using the std::pair
constructor instead.

(This doesn't really matter, because I can't get the dll to work from a
 modern compiler anyway.)
Added bNoCache argument to AI_localDefenceStrength.

The bNoCache argument indicates that we shouldn't update the strength memory.

This is so that we can use AI_localDefenceStrength in asynchronous situations
- such as AI_acceptSurrender - without having to worry about strength memory
causing OOS problems.

Strength memory is still not used for human players.
Added more detail to the debug logging in CvRandom::get.

The log now includes the range of the requested random number.
Adjusted how AttackSea and transports are built in AI_chooseProduction

The new rules are a bit more fussy, so that assault units, transports,
and attack ships are built at a more even rate so that the AI doesn't
end up with far too many one before getting any of the others.
Added additional checks to CvGame::calculateSyncChecksum

Also, the CvMainInterface.py now shows a number to indicate which
checksum has failed based on the current timeslice. (Unfortunately, I
can't guarantee that _all_ the failed checks will be listed, but at
least we'll know that the ones that are listed have failed.)

These changes are only for debugging.
Citizens are once again unassigned before automatic reassigning.

CvCityAI::AI_assignWorkingPlots now removes all citizens from their
plots before reassigning them all one by one. This was the original
behaviour, but I had disabled it for efficiency reasons. I've reverted
the change because my testing has shown that it sometimes produces
slightly better citizen assignment, and it doesn't have a huge impact on
speed. (I had hoped that my rewrite of the juggleCitizen method would be
good enough to not require the initial unassigning, but unfortunately
that's not the case.)
Made several adjustments to CvPlayerAI::AI_unitValue

The 'noCapture' property is now penalised for attack units (to make
gunships a bit less attractive). The evaluation of unit speed has been
adjusted. Collateral damage immunity is now taken into account for city
defenders.

I considered adding some promotion evaluation to this function, but
decided to put it into CvCityAI::AI_bestUnitAI instead.
Rewrote CvCityAI::AI_bestUnitAI. Promotions are now evaluated.

The function has been restructured to remove some loops and improve
clarity. The evaluation of free promotions now uses some simple
heuristics to estimate the quality of each promotion. All free
promotions are now considered, not just the first one from each source.

City defence and city attack now get a value bonus for having at least
one 'good' promotion available to them. (eg. UNITAI_ATTACK_CITY units
which can get city raider are now given some bonus points.)

Removed the evaluation of hurry-rush-happiness. The calculation seemed
to be flawed in a couple of ways which probably made it worse than
useless.
Machine guns can now be UNITAI_CITY_DEFENSE type.

Just a change to the xml. Hopefully this will help the AI use machine
guns more effectively as defenders.
Forest preserves now give +1 commerce.

This is in addition to their previous bonuses.
The open list in KmodPathFinder is now a vector, to improve speed.

Although it seems natural to use a linked list for this, I recently
found out that linked lists are generally slower than vectors even when
deleting and inserting in the middle of the list. I did a quick
experiment to test it, and sure enough, the vector was faster.

Thanks to Bjarne Stroustrup for the tip.
Restructured pathfinder usage to not use getPathLastNode.

FAStarNode pointers returned by the pathfinder become invalid when the
pathfinder is destroyed. Because of this, I consider it bad practice to
use these pointers. In fact, the the pathfinder shouldn't allow any kind
of external access to them at all. Not only could misuse result in
segfaults, but the pointers could also be misused in a way to mess up
the internal state of the pathfinder...

So, in this patch, almost all usage of FAStarNode has been removed from
outside of the pathfinder. This will have no effect on the execution of
the game, but it may help to reduce bugs in the future.

I've disabled CvUnit::getPathLastNode and
CvSelectionGroup::getPathLastNode, and replaced their usage with new
pathfinder methods such as KmodPathFinder::GetFinalMoves and
KmodPathFinder::GetPathTurns.

There are only a couple of places where FAStarNode is still used. One is
in CvUnitAI::AI_solveBlockageProblem, which doesn't use the
KmodPathFinder, so I probably won't change it. The other is
CvUnitAI::AI_considerPathDOW. To correct this, I intend to create a new
method to give access to the completed path without exposing the
internal nodes. (But I haven't done that yet.)

I've also removed the KMOD_PATH_FINDER define and preprocessor
conditions. The original bts pathfinding code has been deleted.
Fixed units getting bumped when simultaneously attacking and defending.

This fixes a bug which sometimes caused units to move onto plots which
still had enemy defenders.

The root of the bug was that when two units attempt to attack each other
at the same time, the game failed to track which unit was in the process
of attacking.

I've corrected this by clearing attackPlot when a unit is defending. And
I've added some additional conditions and asserts to prevent similar
problems in the future.
Simplified the move conditions in CvSelectionGroup::groupMove.

This change should have almost no effect on gameplay.

pCombatUnit now moves first, so that grouped units don't get
unnecessarily left behind if they have the no-capture trait or something
like that. Also, I've removed some redundant checks.

MOVE_THROUGH_ENEMY previously set bCombat = true in groupMove, but this
had no effect on the game since all combat happens before groupMove is
called. So I've removed that combat flag to make it consistent with
other move flags.
Added hint about right click on +/- buttons.

Commerce sliders and espionage weights can be set to max/min quickly by
right clicking their +/- buttons.
Moved FASSERT_BOUNDS to FAssert.h.

FASSERT_BOUNDS is now only defined if FASSERT_ENABLE is defined.
Fixed a minor issue in CvCityAI::AI_bestUnitAI.

One of the asserts is not always true, and it is possible that in some
mods the incorrect assumption could have resulted in a divide by zero.

It would need to be a weird mod, and a very unlucky situation in the
game. Nevertheless, the problem is now fixed.
Made several changes to AI_assignWorkingPlots and related functions.

Once again, I've stopped the city governor from removing all working
citizens when refreshing working plots. There were some minor problems
with my previous changes, and surprisingly they didn't correct the
problems I was hoping to correct anyway. So I've made another attempt to
improve the efficiency and effectiveness of AI_juggleCitizens.

I've rearranged things in AI_assignWorkingPlots so that only the
consistency checks are done before checking for city disorder (eg.
remove citizens from plots they aren't allowed to work, etc. then only
do the other stuff if there is no city disorder.)

And I've tweaked iAdjustedFoodPerTurn in AI_yieldValue to (hopefully)
improve citizen allocation.

I've also added a preprocessor option in AI_juggleCitizens to log some
data for testing.
Changed the core of KmodPathFinder to use a single block of memory.

node_map is now a multi_array<FAStarNode, 2>, and the path finder no
longer uses any shared_ptr.

This change will (usually) use a bit more memory than the previous
implementation, but I expect it to be significantly faster, because
there will be fewer memory lookups and far fewer allocations and
deallocations.

Initial testing suggests this makes the path finder around 25% faster,
but that it is still only a tiny speed boost overall. Apparently I
forgot that the path finding is no longer a large part of the total CPU
time.