Custom variables, part 1

[Taitava]

Discussed in #146

User interface

• I'm thinking about creating a right side pane element for showing a list of currently defined custom variables.

Other features

• Default values: if a custom variable does not yet have a value, a default value for it can be defined in each shell command's settings. Default values are shell command specific, so two shell commands can define different default values for the same variable.
• Each custom variable need to be defined before they can be used, so that SC will know all the available custom variables in each of the features that write or read their values. Defining a variable is not the same as setting a default value for it.

Variable types

• Text: Allows all types of characters. This will be implemented first, other types later.

Internal

• Variable parsing needs to be changed to happen in two phases:
  1. Preparing: Determine which variables will be populated by preactions (e.g. variables filled in a prompt). Parse all other variables in the first phase.
  2. After all preactions are done, parse the rest of the variables.
• Add debugLog() calls.

Settings file

• [ ] Make sure configuration migrations can add new fields to CustomVariables. Edit 2022-04-10: Moved to discussion Migrations: Better support for complex, nested configuration properties #198

Fixes

• Settings: Variable tab lists all custom variables under Built-in variables section. Remove them from there.
• Autocomplete: Make new custom variables appear in the list without a need to reload the plugin.
• Fix: New custom variables are not previewed in Prompts' shell command preview texts.