Expose resolved variant information in bindings

[gbtami]

Fairy-Stockfish already performs the authoritative parsing and processing of variants.ini definitions. This includes applying inheritance, defaults and overrides, resolving piece identities and custom Betza pieces, constructing promotion and pocket rules, processing regions, and deriving the final game-ending behavior.

Until now, applications using the Python or JavaScript bindings had access only to a small collection of individual helper functions. A GUI needing additional information had to parse variants.ini again and try to reproduce part of Fairy-Stockfish’s internal processing.

That approach has several problems:

• inherited properties may not appear in the custom variant section at all;
• defaults and derived values are easy to interpret differently;
• every GUI develops its own incomplete variant parser;
• support for new Fairy-Stockfish rules must be independently reimplemented downstream;
• client-side and server-side implementations can disagree about the same variant.

This PR adds a single authoritative introspection API:

json.loads(pyffish.variant_info("variant"))

JSON.parse(ffish.variantInfo("variant"))

Both bindings use the same C++ serializer, so they expose the same fully resolved information.

The result is versioned JSON rather than a direct dump of the internal Variant representation. Piece sets, enums, bitboards and other implementation details are converted to stable semantic values such as piece names, square lists, booleans and descriptive strings. This keeps the API useful to external applications without making internal enum values or memory representations part of the public contract.

The exported information includes the resolved:

• board geometry and starting position;
• pieces, FEN representations, synonyms and custom Betza definitions;
• royal piece types;
• movement and promotion regions;
• promotion and demotion behavior;
• pockets, drops and capture-to-hand rules;
• castling configuration;
• checking, repetition and game-ending rules;
• extinction, flag, connect-N and enclosing rules;
• gating, walling and special movement behavior;
• protocol-related piece and pocket information.

A concrete use case is pychess-variants’ user-defined variant support. Pychess previously had to infer pieces, promotions, pockets, royal roles and other properties independently on both its Python server and TypeScript client. Inherited pieces that could not be detected reliably even required GUI-specific metadata inside the INI comments.

With this API, Fairy-Stockfish remains the only component responsible for interpreting the variant definition. Pychess and other GUIs can consume the resolved result for rendering, piece-set validation, board styling, editors, rule descriptions and server-side termination handling.

This PR exposes information Fairy-Stockfish has already parsed and resolved, making that information reusable through the existing bindings.

[dpldgr]

Nice. I've been using the #gui_info = ... approach for a bit and it works very well, but it's completely manual endeavour that's easy to get out of sync and make mistakes. Exporting JSON makes sense as it's easy to parse, standardised, and there are a plethora of mature parsing tools/libraries available for just about every common language. Nice work!

[gbtami]

@ianfab what do you think, is this OK or do you have something different in your mind?