Handle different options for castling method

[Jimima]

To support different castling methods in the new lichess mobile app, will open PR over there too

[veloce]

Thanks for the initiative! I don't think we want/need to modify dart chess to support this though.

I based this package on chessops and shakmaty, both used by lichess. And iirc none of them handle different ways of castling. For the sake of simplicity and API consistency I assume.

Which means the logic to support alternative castling methods must be implemented by the lib user only.

[Jimima]

My main reason for involving dartchess is that there is some logic in there for chess960 already so I built on that. I also noticed there is a bug in the current chessground premove implementation that is that it only checks that both the king and the rook are on the initial squares, it does not check (or know) whether casting is possible i.e. the king may have moved and returned to it's initial square. Only dartchess knows this I think. I thought maybe it makes most sense for dartchess to handle all castling logic for this reason but I am a little unsure. Do you think there is a way to just handle everything in the client? I might see how lichess handles it currently...

[Jimima]

Correction: I meant to say dartchess is already adding squares for the castling move being "two squares" vs "king over rook". For consistency it would probably make sense for dartchess to only handle king over rook and for the client to do all the necessary UI stuff to display the user preference but only use kingOverRook when dealing with actually making moves. This is the approach that the UCI specification takes. In any case, I think I agree with you, in the short term I can look at moving this logic out of dartchess and into the client.