Render reduced-strategy labels lazily

[d-kad]

Description of the changes in this PR

GamePlayerRep::MakeStrategy built a text label for every reduced strategy eagerly, scanning all of the
player's information sets with two map lookups each. The label is often never read, and its construction is
O(strategies × infosets) in time and allocations.

This PR makes it lazy. GameStrategyRep::m_label becomes a mutable std::optional<std::string>;
MakeStrategy leaves it empty and GetLabel() renders from m_behav on first access, then caches.
The rendered text is unchanged.

It also replaces operator[] with contains()/at() on the two paths that read m_behav
(the behavior-to-strategy profile constructor and TreePureStrategyProfileRep::GetPayoff).
operator[] inserted a zero for every absent information set, expanding each strategy's map on first read;
the const-correct access preserves the sparsity MakeStrategy produces.

No behavioral change.

[d-kad]

On 16.7.0, labels for all reduced strategies are constructed and held at generation time; for the binary tree at size 20 it exhausts memory and the kernel is killed.

Rendering labels lazily removes that up-front allocation, so these sizes complete

[tturocy]

This is a good idea, but let's trace the implications through even more thoroughly.

Would it make sense simply to have generate-on-demand for the strategic form above a given size? Random access via label is probably not going to be something that makes a lot of sense in a large game.

But also this is flagging up that we are abusing labels in reduced strategic forms to do multiple duties.

And - now that we are requiring labels for actions, the use of numbers for the auto-generated strategy labels is dubious when we could do something derived from the constituent actions.

We should discuss this in our upcoming catchup. We do definitely need to do something along these lines however.