Add reflection to the ActionArgs in the settings model

[PankajBhojwani]

Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values.

Detailed Description of the Pull Request / Additional comments

• The IActionArgs interface now has additional methods:
  • Get the number of args
  • Get/Set an arg at a specific index
  • Get a vector of arg descriptions; the arg description contains:
    • name of the arg
    • type of the arg
    • whether the arg is required
    • a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values)
• All the macros in ActionArgsMagic have been updated to support the new interface
• ActionMap has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel
  • It also handles ID change requests for commands
• EnumMappings have been added to various ActionArg enums that weren't there before

Validation Steps Performed

Bug bashed in conjunction with #18917

[DHowett]

noted

[carlos-zamora]

Suggested change

	_ActionMap.erase(cmdID);
	_ActionMap.erase(cmdID);
	_changeLog.emplace(IDKey)

This one I'm iffy on, so I want to discuss here.

Currently, there isn't a place where we're tracking if a user added an ID. In the JSON, the user would be using "id" in two cases for Action Map:

1. create a new action in the "actions" block (i.e. {"command": "terminalChat", "id": "User.terminalChat"})
   • That's fine? We care about action arg usage and that's already being handled.
2. create a key binding in the "keybindings"block (i.e. {"id": "User.terminalChat", "keys": "ctrl+?})
   • That's fine too. We care about "keys" usage and that's already being handled.

(related: "id" is used in the new tab menu, but we're just tracking "action" there which is sufficient)

Long-term, however, we want _changeLog to be a way for us to know if the user changed anything. So maybe we do want to apply the code suggestion and update case 1 to add "id" too? Thoughts?

[PankajBhojwani]

This one is tough because I imagine most users won't be actually adding their own IDs - it will just be autogenerated for them. So distinguishing between us generating an ID for them vs an ID they added or changed is... tricky

[carlos-zamora]

This looks great! Really just blocking over the missing SaveSnippet name in the map (the other two are a question and a suggestion). Nice work!

I'll come back and approve when that SaveSnippet comment gets resolved. I'll have to come back and approve it anyways haha.

[DHowett]

16/18 files reviewed

[DHowett]

can we not treat required as a true boolean? Is is because sometimes we have required be based on other properties?

[PankajBhojwani]

required is definitely a misleading word here, it's more like validation i.e. it takes the form of something like this: args->Commandline().empty() (in the case of EXECUTE_COMMANDLINE_ARGS for example). So what we're doing here is something like "this arg has a validation, therefore it is required" which isn't technically correct but works since the validation is all "this cannot be none/empty"

[DHowett]

(note that using RS_ means it expands in the local language immediately on creation, rather than later during use)

[PankajBhojwani]

Yes, I believe we discussed this and agreed to have it be this way for now because otherwise we would need the resource strings on the editor side