TODO

* Make UCI options case-insensitive
  UCI standard says than UCI options are case-insensitive, but they are case-sensitive in the
  current implementation. We need to patch the `OptionStorage` class and all the observers that
  check for option name. Do not forget to update UCI name escaping and baseline tests for UCI.
  Better verify all the usages of UCI options whether they are still correct. Finally, state in
  the docs that the options are now case-insensitive.

* Write stricter `ValidateBoard`
  Add more heuristics to check that the board is theoretically possible, i.e no more that 9 queens,
  10 knights, 10 bishops etc. Now we check only for one king and no more than 16 pieces. This may
  be good as it makes impossible to create a position in which the quiescense search runs for too
  long. (Currently, the position with 15 rooks on both sides may hang the engine.) The downside is
  as follows: some chess GUIs may accept the positions which won't pass our `ValidateBoard`, and
  will think that our engine behaves incorrenly in such case. Another idea for board validation is
  to prevent triple and impossible checks. Chess package for Python does this, see its sources:
  https://github.com/niklasf/python-chess/blob/v1.6.1/chess/__init__.py#L3282. Maybe we can invent
  even more heuristics.

* Rethink the Client/ServerConnector architecture
  The architecture where each `Client` is connected to `ServerConnector` and each `Server` is
  connected to `ClientConnector` is good now, but has some limitations which may arise in the
  future. For instance, we may write an engine adapter, which will allow to launch an engine
  without creating a `Server` instance. In this case it's not good to write a `ServerConnector`,
  as the interactions with the client will be outside of `poll()` method, so implementing `poll()`
  would be useless. Another thing worth rethinking is thread-safety. Currently, `Client` and
  `Server` are not thread-safe, while `ClientConnector` and `ServerConnector` are thread-safe.
  When we get rid of the current architecture, we will need another approach to define what must
  be thread-safe.

* Do not analyze the same node twice in multiple threads
  To do this, we may put a flag `busy` into the hash table, which indicates that this position is
  already being analysed. If we encounter a busy position during the search, we just skip it and
  say that we'll analyse it in the end. Such trick may improve performance of the engine in the
  multithreaded case. This idea is used in Texel chess engine, so we may also try it.