Make label normalization mandatory and collision-safe, and retime it for players and strategies

[d-kad]

Issues closed by this PR

• Contributes to [ENH]: Require unique labels for game objects (within appropriate scope) #861
  (normalization foundation; enforcement to follow in a later PR)

Description of the changes in this PR

Prepares the label-normalization path in the file loader for the unique-nonempty-label enforcement
planned in #861. Loading accepts files with empty or duplicate labels, with labels "unique-ified" as before.

Three self-contained commits:

• Mandatory normalization. Label normalization on file read is now unconditional
  (the previous opt-in parameter is removed), so every loaded game has normalized labels.

• Collision-safe normalization. NormalizeLabels now tracks the labels already used
  in each scope and never generates a duplicate suffix, so an input like {"x", "x", "x_1"}
  no longer renumbers to a second "x_1". NormalizeLabels is generalized to work over
  both game-object containers and raw label-string lists via accessor lambdas, with a
  NormalizeLabelStrings helper for the string case.

• Retime player/strategy normalization ahead of construction (revertable). Player and strategy labels
  are normalized on the raw label lists read from the file, before the game objects are constructed,
  rather than renaming objects afterwards. This is a step toward retiming normalization planned in
  [ENH]: Require unique labels for game objects (within appropriate scope) #861.

Actions and outcomes are deliberately not retimed here

Both are multi-reference scopes: an infoset's actions are re-stated at each later node and
validated by CheckInfosetActions, and outcomes are keyed by id across the whole tree via the
outcome map. Normalizing their labels at first definition makes the later raw re-statement no longer
match what was stored.

Retiming actions breaks loading when an infoset has duplicate action labels (so normalization changes
them, e.g. { "1" "1" } → 1_1, 1_2) and is referenced at more than one node (so CheckInfosetActions
re-checks it against the raw labels) -- resulted in 8 test failures.

[tturocy]

• Move the checking into C++ SetLabel() (and we don't need it in pygambit then)
• Adding new objects (in C++) should require a label (and raise an exception if it is not valid or unique)
• pygambit API will make label required (not optional) for new objects

[d-kad]

@tturocy one thing to confirm:

As per Bullet 2, user creation requires a valid unique label.

The one thing I want to confirm is the parser: it creates outcomes from file labels (can be empty/duplicate), so raise-on-duplicate there would break loading — am I right that we also want readers to accept those and generate _1/_2. Those only fit if the parser's exempt from the rule (sets labels non-enforcing, normalization after) -- is this the plan to follow?

Please let me know if you want loading strict instead, I'll rewrite the test games.

[tturocy]

This is a good catch, I had mis-remembered how I implemented the normalisation. Normalisation in the loader is done after the game has been constructed, rather than as the file is read. So you're correct SetLabel would fail under the new semantics.

Our thinking when we introduced this normalisation is that there are potentially too many files out there with empty labels (in particular), which requiring unique labels will break. So we want to continue the behaviour of the loader to "unique-ify" labels. However this normalisation has to get moved now.

Probably, the right way to do this will be to make a separate branch and change the timing of the normalisation, so it's being done on the raw lists of labels rather than the game objects, and we'll merge that first. Then there won't be a clash with the new SetLabel semantics that throws an exception on duplicate.

[tturocy]

Well, there's good news and bad news on the tests - it's good that it looks like our new BAGG checks are doing something, but it is puzzling that it is crashing on MacOS only (while I have tried locally on this branch on MacOS and do not have a problem...!)

[d-kad]

@tturocy, I pushed a fix for the AGG/BAGG parser crash blocking CI, as its own PR #971 since it's a master bug rather than label normalization work.

Once #971 merges we can rebase this branch onto master and drop the fix from here, so this PR remains just the normalization work.