Make en passant more flexible

[alexobviously]

Original comment: Should probably roll enPassant and firstMoveRanks into one EnPassantOptions class, to match the new paradigm and clean up all the chess-specific stuff in Variant.

But I've also realised that there are some more complex versions of en passant that we probably want to support. For example, when pawns can move 3+ spaces on the first move, it should be possible to capture them en passant on any of the intermediate squares (see: wildebeest chess, chess on a really big board).

I think the solution is to make en passant an implementation of the upcoming custom move generator, and have the en passant options param at the variant level just compile to a custom generator.

Another issue is with storing en passant squares in the state and zobrist hash. I think we can safely make it a list of ints in the state, and maybe just store one in the hash.

[alexobviously]

A limitation: statelessly calculating the piece to be captured en-passant doesn't currently work.
e.g. if you start a berolina chess game from a FEN position where there's an EP square defined, it will be possible to move to it but the moving piece won't be captured.
Playing through the whole game and making the same enpassant move will work, it's just if you start from a position with EP possible.

Another related but different problem: even if this is fixed, variants like berolina where multiple pawns can end up on the same square on the first move (e.g. a2c4 and e2c4) won't be able to disambiguate without extra info in the FEN.