Fix free constant init value handling for documented dict inputs

[julian-8897]

Summary

Hi Wassim, I opened this PR to fix a small mismatch between the documented API and the
way free constant initial values were handled internally.

ClassSR documents spe_free_consts_init_val as accepting a
dictionary keyed by the SPE free constant name, eg. {"k0": 1.0, "k1": [1.0, 1.1, 1.2]}.

But in check_library_args, that value was still being treated like
an ordered sequence. So passing the documented dict form would try
to access spe_free_consts_init_val[0], which raises KeyError: 0.

The fix is to normalize the input once, before args_make_tokens is
built. After normalization, both supported forms end up as the same
name-keyed dictionary internally: [1.0, 2.0] and {"k0": 1.0, "k1": 2.0} both become {"k0": 1.0, "k1": 2.0}.

I also applied the same normalization to
class_free_consts_init_val, since that argument is documented as
accepting dict input as well and had the same kind of mismatch.

Tests

I added some focused tests for:

• spe_free_consts_init_val=None
• ordered SPE scalar values
• ordered SPE per-realization arrays
• SPE dict scalar values
• SPE dict per-realization arrays
• class free constant None, sequence, and dict inputs
• construction through codec.get_library and FreeConstantsTable

I ran MPLCONFIGDIR=/private/tmp python -m unittest physo.task.tests.args_handler_UnitTest and MPLCONFIGDIR=/private/ tmp python -m unittest physo.toolkit.tests.codec_UnitTest.

Both pass