feat: support multiple inline piece sets

[BilgeGates]

What problem does this solve?

The library ships exactly one inline piece set (CBurnett) via PIECES /
getPieceSVG, but PIECE_SETS advertises 23 sets and the app exposes them as a
user choice. Consumers who want a different look (e.g. Merida, Alpha) can't get
the matching SVGs from the package and must source them elsewhere — defeating the
"no CDN, self-contained" promise.

Proposed API

Add additional inline piece sets and let getPieceSVG select one, while keeping
the current single-argument call working (defaults to CBurnett).

// Existing (unchanged) — defaults to the cburnett set
getPieceSVG('K'); // -> '<svg ...>'

// New — choose a set by id
getPieceSVG('K', 'merida'); // -> '<svg ...>'

// generateDiagram gains a pieceSet option
generateDiagram({ fen, pieceSet: 'alpha' });

Notes / acceptance criteria

• At least 2–3 additional sets bundled (license-compatible, e.g. Lichess sets under their licenses).
• getPieceSVG(piece) stays backward compatible (cburnett default).
• Unknown set id falls back to the default (no throw) or returns null — decide and document.
• Bundle-size impact measured and noted; consider tree-shaking so unused sets don't ship.
• PIECE_SETS entries that have inline SVGs are distinguishable from those that don't.

Alternatives considered

Keeping a single set and pointing users to external assets — breaks the
dependency-free, self-contained design and the offline/SSR use case.

Additional context

Bundle size is the main design tension: 23 full sets would bloat the package.
Likely approach is a small curated default plus optional set modules, or a
sub-path export per set so bundlers can drop unused ones. Targets v1.2.0.