Refine `PieceSpec` for custom angles, suits, ranks, cfg?

[trevorld]

• Currently use ,aANGLE, ,sSUIT, ,rRANK, and ,CFG'
• If we start the angle, suit, rank forms with numbers can probably eliminate trailing ' in ,CFG'...

[trevorld]

Tradeoffs of dropping the trailing '

The "terminate at next , or @ or whitespace" rule works cleanly for most cfg names:

Bd6,dice_d4,a45@a1   → cfg=dice_d4, angle=45  (the ,a45 terminates the cfg name)
Bd6,dice_d4@a1       → cfg=dice_d4             (@ terminates)
Bd6,dice_d4          → cfg=dice_d4             (whitespace terminates)

However several cfg names returned by piecepackr::game_systems() contain underscores: dice_d4, dice_d6 (etc.), playing_cards_tarot, playing_cards_expansion, dual_piecepacks_expansion, icehouse_pieces. The _ is also a PPN move token, and the underscore token regex (?<![(<,])_ only excludes _ preceded by (, <, or ,. A _ inside a cfg name like dice_d4 is preceded by e, so it would be mis-tokenized as a move token in a _ move context:

Bd6,dice_d4_b4   ← ambiguous: cfg=dice_d4 + _b4 move, or cfg=dice + d4_b4 garbage?

Digits within cfg names (e.g. checkers1, chess2, dice_d4) are not a problem — once the parser has established it is reading a cfg name (first character after , is not a/s/r followed by a digit/-), it reads freely until the next terminator.

Option A: keep ' as optional escape

Drop ' for simple names, keep it for names containing _:

Bd6,piecepack@a1       ← no ' needed
Bd6,dice_d4'_b4        ← ' still needed before _ move token

Teaches as: "add ' if your cfg name contains _."

Option B: use trailing , as escape

A trailing , terminates the cfg name, needed only when the cfg name contains _ and is the last comma-prefixed spec before a _ move token:

Bd6,dice_d4,_b4        ← trailing , disambiguates

This is consistent with the existing comma-as-separator grammar. The downside is Bd6,dice_d4,_b4 has a visually odd ,_ juxtaposition, and the trailing-comma concept is only needed in a narrow edge case (cfg with _ as the last spec before a _ move).

Practical note

The ambiguity only materialises when identifying an existing piece by its cfg name in a _ move. In practice, pieces are usually identified by coordinate or ? query rather than by cfg, so this edge case may be rare enough that either option is acceptable. The @ move context (placing new pieces, the most common use of cfg) is unaffected either way.