Implement a new method on Position that evaluates whether the active color can castle
on a given wing of the board. Then, implement making a castling move in the position.
Make a new Wing enum in the core crate to specify kingside or queenside. Replace the
Castle enum from the board crate with this one. This caused a lot of churn...
Along the way fix a bunch of tests.
Note: there's still no way to actually make a castling move in explorer.
Implement thiserror::Error for a bunch of error types, and remove string errors
from the implementation of the command handler in explorer.
Clean up parsing of basic types all over the place.
Update Cargo files to include thiserror and anyhow.
Rework sight.rs and add a new module, movement.rs, to calculate piece sight and
movement. I discovered during this process that "sight" and "movement" are different
because pawns (in particular) can move in ways that don't follow their sight lines.
The routines in the movement module account for this, but also pass through to the
sight routines for other pieces.
Add two BitBoard attributes to the struct that mark squares that should be marked
or highlighted.
Empty marked squares are shown with an asterisk (*). Marked squares with a piece
don't have any change of appearance. (Something I'm still thinking about.)
Highlighted squares are shown with the ANSI escape sequence for Reverse Video.
Encapsulate castling rights within a small module. Castle provides the API to the
rest of the board package. Rights encodes the castling rights for each player.
Parameters defines castling parameters for each player.
Add chessfriend_bitboard::IterationDirection
Make BitBoard::occupied_squares() take an IterationDirection and return an iterator
corresponding to the direction.
Do the same for ::first_occupied_square().
Now that board has a Mailbox, the implementation of this routine can be greatly
simplified. Instead of needing to iterate through all BitBoards to find the
occupied square, just consult the mailbox.
