Prevent/remove empty inequalities sub-key lists when writing user selections to params

[matt-dray]

In @tomjemmett's original wording:

guessing we may have an issue to deal with when we implement inequalities in the inputs app, because you could have a situation where you enable an item, disable it... does that cause R to then have an empty list which would get turned into an empty dict? would need to pop those out. so might be worth adding in some guard code in the mod_run_model_fix_params function?

In v4.2, the model and json schema were updated to accept the params inequalities key in this format:

"inequalities": {
  "level_down": ["HRG1", "HRG2"],
  "zero_sum": ["HRG3"],
  "level_up": ["HRG4"]
}

The model and schema accept the sub-keys (level-down, zero sum and level-up) as empty lists [] or to be missing entirely.

Note that the inputs selection app sets (or upgrades) inequalities in default params with an empty dict in the form "inequalities": {}. It does not set empty lists beneath it.

The inputs app proper has some code that replaces empty elements because handling json in R is a pain. It will see an empty [] and replace it with {} (all other keys in params are dicts), which will cause the json schema to fail (becuase it expects [] for inequalities sub-keys).

This needs consideration in nhp_inputs code when writing user inputs to the params file. Adding an HRG code and then remove it might result in an empty [], which could be converted erroneously to {}. I think there are two main options to resolve this:

1. Add special handling for inequalities in recursive_nullify().
2. Ensure empty sub-keys are removed entirely.

Option 1 is sub-optimal: it requires special hard-coded handling to ignore inequalities and would cause problems if any other element in params gets called 'inequalities' in future (we created a sketch for this already and decided it wasn't great). Option 2 is better: storing empty lists for the sub-keys is unnecessary but requires code to check for emptiness.