I was given some guidance[1] on the Rust developer forums that my approach of
implementing Iterator on these types wasn't quite right.
> In general, iterators are distinct data structures than the primary struct
that owns the data, in part due to issues like this, but also due to concerns
around iterator invalidation and the need to carry around iteration state more
generally.
I took this to heart and replace the Iterator implementations with an iter()
method that returns an `impl Iterator<Item=Move>`. This works so much better and
lets me delete a bunch of code!
Additionally, the iter() methods on the piece-wise move generator types return
`impl Iterator<Item=&Move>`, and then the top-level Moves::iter() returns a
.cloned().
Overall I'm really happy with this!
[1]: https://users.rust-lang.org/t/tricky-lifetime-may-not-live-long-enough-error-on-an-iterator-wrapping-a-boxed-iterator/104650/3
Holy heck I went on a *journey* here. Ultimately, I needed to implement my own
index-based iterator instead of using the Vec's Iterator.
This type establishes some patterns I want to carry forward to other move
generators.
1. The use of a Parameters struct to fully parameterize the move generation
per-color. That lets these types only need a single color-based branch
2. A list of move lists, one list for each of captures, promotions, and quiet
moves.
3. An index-based move iterator.
4. Separate impl for generating bitboard representations of these moves
Additional changes:
- Implement BitBoard::from_square()
- Implement a Square::e5() for tests
This class doesn't implement en passant yet. It also doesn't yet have tests for
the bitboard stuff.
