feature(sct_config): appendable configuration values

[fruch]

introduce new option for appending to string or list configuration values

1. strings: can be appended with adding ++ at the begining of the string:
   export SCT_APPEND_SCYLLA_ARGS="++ --overprovisioned 1"

2. list: can be appended by adding ++ as the first item of the list
   export SCT_SCYLLA_D_OVERRIDES_FILES='["++", "extra_file/scylla.d/io.conf"]'

Note list would work on every config defiend with str_or_list_or_eval with the expection of config_files, region_name, gce_datacenter and gce_datacenter which can't be appended, and would need to be overriden completly

Ref: #7653

Testing

• [ ]

PR pre-checks (self review)

• I added the relevant backport labels
• I didn't leave commented-out/debugging code

Reminders

• Add New configuration option and document them (in sdcm/sct_config.py)
• Add unit tests to cover my changes (under unit-test/ folder)
• Update the Readme/doc folder relevant to this change (if needed)

[dimakr]

LGTM

[soyacz]

we should somehow document it.
Maybe configuration_options.md could have few remarks before options table stating that e.g dicts are merged, or str/lists can be appended like that?

[fruch]

we should somehow document it. Maybe configuration_options.md could have few remarks before options table stating that e.g dicts are merged, or str/lists can be appended like that?

all strings configuration can be used like that, and everything with type=str_or_list_or_eval

the configuration_options.md need rework anyhow, it's not really usable nowdays (after github redo their UI)

[fruch]

we should somehow document it. Maybe configuration_options.md could have few remarks before options table stating that e.g dicts are merged, or str/lists can be appended like that?

all strings configuration can be used like that, and everything with type=str_or_list_or_eval

the configuration_options.md need rework anyhow, it's not really usable nowdays (after github redo their UI)

#9558 should make that doc a bit more usable
and then we can introduce the information like which one is appendable on the docs

[soyacz]

Assuming we're going to document it in followup - LGTM

[fruch]

Assuming we're going to document it in followup - LGTM

now with the docs update, that would specific which one can be appended and which one can not.
not sure it's clear enough

[soyacz]

I don't see the code that verifies 'appendable' - shouldn't it be added and fail fast?

[vponomaryov]

LGTM

[soyacz]

LGTM