Well… all the tests except the Peter Ellis Jones tests.
Pass around whole EnPassant types instead of pulling out just the e.p. square.
Make sure that Castling moves have their target and origin squares populated.
Add a color field to the Castle move style to make this possible.
Add a field to MoveSet called special that flags special moves that should be
generated in the iter() method. This field is a u8. It only tracks castles in
the first and second bits (kingside and queenside, respectively). The move iterator
chains two maps over Option<()> that produce the kingside and queenside castle
moves.
With that done, finish the implementation of Position::player_can_castle by
adding checks for whether the squares between the rook and king are clear, and
that the king would not pass through a check. This is done with BitBoards!
Finally, implement some logic in PositionBuilder that updates the position's
castling flags based on the positions of king and rooks.
Supporting changes:
- Add Color:ALL and iterate on that slice
- Add Castle::ALL and iterator on that slice
- Add a CastlingParameters struct that contains BitBoard properties that describe
squares that should be clear of pieces and squares that should not be attacked.
