 + only set EP square (in hash table at least) if an EP capture is
   possible. This should improve use of the transposition table in
   situations where the same position can be reached with double or single
   pawn moves.
   FIXED.

 + There is something very wrong with the evaluation of WAC.244...
 + Check extensions don't work as they're supposed to...
   It turned out it wasn't a problem with check extensions per se, but an
   interaction between check extensions and the implementation of recapture
   extensions. Fixed by not following every recapture exchange, since most
   of them are meaningless anyway.

 + Use history heuristic during the initial phase of the search, to improve
   move ordering at shallow search depths. Similarly, it may also help
   during IID, though there we may run into the problem that wiping the
   table before the IID might be slow...
   UPDATE: Tested; actually this doesn't help at all...

 + There is a bug that corrupts the display of moves in the move list after
   taking back a move and then advancing again. Positions are fine,
   however.

 + Rule-of-the-quadrant for pawn endings will also be good to have to
   evaluate them (somewhat crude at the moment, but it helps).

 + Currently, the engine does not generate en-passant captures while doing
   out-of-check moves.

 - Improve king safety evaluation. It's a mess right now.

 + Add an age field to the transposition table:
   when a position is stored (or retrieved), set its value to 5 (or 10,
   say).
   Then, before the start of each search, go through the hash table and age
   all entries by 1. If an entries age becomes < 0, it can always be
   overwritten. Evidently, we only need to do this in the depth-priority
   table.

 - Work out why there are some regressions in WAC test scores
   By now, the program has solved every position in the WAC test suite at
   one point or another, but never all at the same time.
   With Berliner's pawn evaluation, the program finds 92 and 243, without
   them it finds 31 and 275. Other than these 4, results are identical
   between these pawn evaluation terms.

 - Some WAC positions are not found because the program prunes too
   agressively (the problem with the type-B approach). We either need some
   sort of (static) threat detection, or a way to limit by how much the
   move is allowed to be reduced. Late move reductions ("history pruning")
   decreases the depth too much on some interesting lines.
   Maybe also look into history reductions.

 - Another idea, that may only work well for test positions and not in
   games, is the following: if after a 10 ply search with very agressive
   pruning we haven't found any way to improve our position, then do
   another 10 ply search with less agressive pruning and see whether we can
   find a better line of play.

 - Yet another idea is to use parallel search in another way: search the
   position using different levels of agressive pruning in parallel.

 - A move-ordering tidbit by Robert Hyatt (which we can probably get right
   by using piece-square tables):
   ``"pseudo-ordered" is a good term. For each piece, I generate moves from
   most advanced destination to least advanced destination. As far as the
   base ordering, I generate castling, then knights, bishops, rooks,
   queens, kings, then pawns. Always choosing the most advanced of a piece
   type when there are two or more of that piece present.''

 - The engine sometimes takes too long to solve WAC positions; it should
   see some threats or mates much sooner than it does. This could be an
   issue with check extensions not working properly as they should.
   The explosion in search time when there are queens on the board also
   does not help...

 - Enhanced transposition cutoffs: generate hash keys for all successors;
   if one of these is in the table and generates a cutoff, we're done.
   Perhaps this can also help with move ordering? If a move is expected to
   fail low, sort it lower down in the table...
   Implemented: either buggy, or it doesn't help, because the runtime
   increases.

 + Keep track of whether we are in a PV node or not: at the root, simply
   pass "true" if the move being searched is the best move candidate, then
   propagate that down to the leaves.
   Then we can decide not to do some reduction in PV nodes.

 + If the hash table move is available, try it first, before going into the
   main search loop. If it causes a cut-off, we saved a call to qsort.
   This gives a nice 5-6% speedup.

 + Add countermove heuristics

 + Add repetition detection hash table

 + Add the 50-moves-draw rule

 - Idea: Generate piece square tables based on pawn structure and the
   location of the two kings. Before the search, initialise these tables
   with values based on the current position. When doing move ordering,
   use the difference between square values to sort regular moves
   (reduction candidates). When it becomes time to do the evaluation,
   we can recompute the tables (if needed, or look them up in a hash table)
   and compute accurate scores for the pieces. For lazy evaluation, we
   could use the score based on the old tables.

 - Fine-tune check evasion move generation. We don't need to examine the
   entire region covered by a super piece, only for moves that capture a
   checking knight, an attacking piece next to the king and moves
   intersecting the ray of an enemy piece attacking the king.
   Also add a function to check whether a move will check the opposing
   king.
   This can be done relatively cheaply by identifying locations where a
   piece may move in order to check the king. Discovered checks are a bit
   harder, but it is probably still cheaper than the current way...

 - Keep a copy of the PV and use it to seed positions in the hash table, so
   that the hashtable will always contain the PV.

 - Keep a copy of the previous PV as well: if the new PV is shorter than
   the old one (truncated), then do the following: first re-seed the
   hashtable with the old PV (take care not to overwrite newer evaluations
   though!), then seed it with the new one. This gives us the best chance
   of having a complete PV available in the hash table.

 - Return search depth information from alpha beta: depth/q depth for the
   present variation.

 - Make sure move comparisons are using the 64 bit comparison (in the
   union) rather than checking every element in the struct. Can see this by
   disassembling the output, or just rewrite to make sure this is done.

 - Fractional extensions (except during QS)

 + Mate validator: if we've previously scored this position as a forced
   mate in N ply, don't stop the search until we find at least a mate-in-N.

 - Add attack-from square information:

   bitboard_t attacked_from[64];

   where each bit corresponds to a square holding an attacker. When making
   a move, do the following:

      1. Remove attacker on target square (if any)
      2. Place new piece on target square
      3. Remove piece from old square
      4. Remove attacks from piece at old square
      5. Add attacks from piece at new square
      6. Update sliding pieces attacking the old square
      7. Update sliding pieces attacking the new square

   Many of these can probably be done by just a few bit masks/xors and
   should be relatively fast.
