Reorganize

Since everything is in a single directory right now the number of files
will grow beyond just the core library. For the time being use file name
prefixes to clarify what is where.

The core library files will remain unchanged.
The utilities will start with "util-".
Engines will start with "engine-".
UCI engine start

This is mostly a prototype engine. It will work against the UCI protocol.

The spec states that all communication is through stdin and stdout. The
following statements make this a little more interesting than simply a
list of writeln statements:
1) The engine should boot and wait for input from the GUI...
2) the engine must always be able to process input from stdin,
   even while thinking.
3) a stop command is received from the UI
   stop calculating as soon as possible (a command from the UI)

It appears that the UI contains all three parts of MVC.
In the minimal case, it appears that an engine could function with simply
a model of the board surface (i.e. the ability to generate and make/undo
moves). Additionally, it can optin to provide its own opening book and
endgame database support. An engine also needs to implement pure
coordinate notation de/serialization for move transmission.

The three statements above mean that the engine needs to implement
continuous polling on stdin to receive input from the UI
(eventing/reactive style would be nice if possible).
And an asynchronous model of computation so that searching will
not interfere with transmission processing.

This commit of main() contains a simple continuous-polling loop on stdin.
It is a proof of concept.
Enqueue commands from the UI
Command processing

Process the commands received from stdin on a thread other than the stdin
read-loop.

This POC gets the command and sends it to the processing thread.
The processing thread enqueues the command.

This might be the wrong place to parallelize but the idiom will be useful.
See how far this style will go before skipping UI commands
Implemented the skeleton for UI commands

Not all commands have a counterpart for this simple engine.
In particular, search should not really require a separate thread. Still,
the idiom will be broadly useful in other engines so I am fleshing it out
here.

There are couple of areas that need to be implemented to finish the UI
commands. For example, I have added two methods to BoardSerializer to
implement a custom de/serialization for sending the board accross thread
boundaries. However, as I was typing this I realized that the original
string could simply be sent and no custom protocol would be needed. Will
adjust in the next commit.

The engine does not actually select a move yet.
Search async design progress

The concurrent code for such a simple search is difficult to build
concurrency around so it might be best to use straightforward linear style
and assume low-overhead unless a profile shows otherwise.

Board/Surface redesign considerations

The commented-out code on lines 98 through 100 seem wrong.
For one thing, makeMove and undoMove are not public. The idea was to make
tryMakeMove the public-facing method. In reality, there is no reason to
convert to string and back to Move types inbetween. In any case, there
should be a public-facing undo-move method.

This calls for a melding of the board and surface api as they are not
really that different.

Without being too hasty, tryMakeMove is useful to make moves sent from the
UI. It is not, however, useful for moves generated in-house. Need to make
that use-case more streamlined.

Do we need to keep track of game move/surface history?
It is necessary for search evaluation, the 50-move rule, and three-fold
repitition detection. It seems like Board could go on a diet as the UI
takes care of these things, along with the game history.

On the other hand, the split between Board and Surface is nice from the
point of view of check detection on attempt-moves. Of course, that is due
to the desire to avoid manipulating the history records, etc.
Rename GameInfo to BoardInfo

It seems good to keep these values in a separate struct.
The values have a consistency feel. Also, a separate file keeps their
tests separate from those of movegen and other surface tests.

It would be possible to remove the half-move clock and fifty move number
from make/undo-move methods. However, they would have to be maintained in
a different location. Although the UI takes care of these values
redundantly, and they are not technically necessary for move generation,
they are necessary for FEN serialization.

Since FEN serialization is not necessary for a UCI engine implementation
those two values may be removed later. Still, at the moment, I am
reluctant to remove the work.
Removed MoveHistory
Do not need a separate store for the current BoardInfo
Fixed case
Maybe the name change will make me like it more
This compiles. Need to check unit tests
Unit tests pass
Reduce the complexity
Removed the needless memcpy when accessing the parsed board

The value-type Stack.top loses its byref accessing when a copy is made.
None of the edits made to info were sticking in history.
Updated the readme
Simplify

Removed the concurrent search since it simply gets in the way of this POC.
All that needs to be accomplished here is to read from and write to a UCI
UI successfully. The move made is random. Algorithms should be quick
enough to avoid concurrency. At least that's the theory.
Renamed two methods
Random engine Entropy ready to test

Cleaned up move de/serialization a little bit.
Since no real searching occurs in the engine the only engine-side command
that it was lacking was "bestmove".