Fix Chess960 regression

Introduced by me in before 1.9 and found by Tord that says:

The 'isChess960' slot in the 'Position' class is currently
set depending on the initial files of the rooks, and not on the value
of the UCI_Chess960 parameter. This is incorrect, as there are lots of
Chess960 positions where the rooks start on the usual files. As a
consequence (unless I am missing something), Stockfish will occasionally
output castling moves as e1g1/e1c1 rather than the correct e1h1/e1a1 format
in Chess960 games. It is possible that some or even most GUIs are robust
enough to accept both notations, but I wouldn't bet on it. And in any case,
Stockfish's behavior clearly violates the protocol.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

src/position.h

@@ -138,7 +138,7 @@ public:
 
   // Text input/output
   void from_fen(const std::string& fen);
-  const std::string to_fen() const;
+  const std::string to_fen(bool isChess960) const;
   void print(Move m = MOVE_NONE) const;
 
   // Copying
@@ -258,7 +258,6 @@ public:
   // Other properties of the position
   bool opposite_colored_bishops() const;
   bool has_pawn_on_7th(Color c) const;
-  bool is_chess960() const;
 
   // Current thread ID searching on the position
   int thread() const;
@@ -323,7 +322,6 @@ private:
   int castleRightsMask[64];
   StateInfo startState;
   File initialKFile, initialKRFile, initialQRFile;
-  bool isChess960;
   int startPosPlyCounter;
   int threadID;
   int64_t nodes;
@@ -553,10 +551,6 @@ inline bool Position::has_pawn_on_7th(Color c) const {
   return pieces(PAWN, c) & relative_rank_bb(c, RANK_7);
 }
 
-inline bool Position::is_chess960() const {
-  return isChess960;
-}
-
 inline bool Position::move_is_capture(Move m) const {
 
   // Move must not be MOVE_NONE !