enable modifier groups in SparseML recipes

[bfineran]

This change will enable SparseML to parse multiple lists of modifiers (groups) from a recipe. The resulting structure will look like this:

training_modifiers:
  - !EpochRangeModifier
    ...

  - !SetLearningRateModifier
    ...

pruning_modifiers:
  - !GMPruningModifier
      ...
  - !GMPruningModifier
        ...
  - !GMPruningModifier
        ...

quantization_modifiers:
  - !QuantizationModifier
      ...
  - !SetWeightDecayModifier
      ...

All modifiers will be parsed into a single Modifier list at run time. Not adding any filtering in the lists to see if they are actually of modifiers, so the user will be able to see any errors if the recipe is incorrect.

[natuan]

Given this will get more interesting, should we have some unit tests for it?

[markurtz]

I like the simplicity, need a bit more visibility into the parsing for the user and I agree with Tuan on getting some unit tests in

[markurtz]

if a user accidentally mispells a group, we'll have a silent ignore here. We should at least warn if a key doesn't have modifiers in it and won't be used, and potentially could throw an exception here to be explicit since we aren't supporting anything else currently

[bfineran]

agreed. this was definitely a concern the issue is that not every top level dict element will necessarily be a modifier list. We could have for instance a list of parameter names stored as a variable to reference elsewhere. If this wasn't the case I would not have required "modifier" to be in the name at all.

One alternative is we could search all lists for BaseModifier objects and flatten that way, letting group names just be for organization.

[bfineran]

Actually, will raise an error when a Modifier object is found outside of a named "modifier" list. That way we could keep the YAML flexibility, but enforce some simple structure in how modifiers are defined.

[bfineran]

@markurtz @natuan updated with unit tests and validation for modifier list names.