Add presets to UserConfig

[oomek]

Test layout:
layout-presets.nut.txt

Needs to be thoroughly tested. I'm not going to insist on adding it to 3.2.0

[Chadnaut]

• Presets don't re-apply pill glyphs when applying Yes/No values
• Presets that change other presets are buggy (nested presets would be very handy)
  • Works somewhat if the child preset is after the parent preset
  • However the child preset remains greyed out even if changed afterwards
  • Child presets before the parent preset don't update their values correctly (it takes another round of saving).
• Presets don't need options since the labels are already in the presets table
  • Or you could do it the other way around - have the presets table in options and remove the presets property
  • This might be a good precursor to allowing options that have labels different to their values - if it's a string then split it, if it's a table then use key/value pairs...
• Presets are mixing json syntax with table syntax, which is valid but may be confusing
  • json: "Preset 0" : {...}
  • table: ["Preset 0"] = {...}
  • The majority of Squirrel code I've seen has used table syntax
• An enum for the option opaque values might be better than supporting comments // 1=is_input, 2=is_function, 3=is_preset
  • There's "magic" opaque values everywhere - should be on our todo list...

[oomek]

Presets don't re-apply pill glyphs when applying Yes/No values

I'll look into it

Presets that change other presets are buggy (nested presets would be very handy)

Nesting was just an idea after I pushed this PR, so I'm not surprised it does not work.

Presets don't need options since the labels are already in the presets table
Or you could do it the other way around - have the presets table in options and remove the presets property
This might be a good precursor to allowing options that have labels different to their values - if it's a string then split it, if it's a table then use key/value pairs...

It's a good idea.

Presets are mixing json syntax with table syntax, which is valid but may be confusing

I personally prefer json syntax so I can have spaces in the name and there is no need for square brackets. Further discussion needed.

An enum for the option opaque values might be better than supporting comments // 1=is_input, 2=is_function, 3=is_preset

I've come up with the same conclusion, but left it for later