feature: add experimental features flag to be only accessible in core config

[leondz]

add facility to unlock experimental CLI options if a core config flag is set

Verification

• run python -m garak --help, experimental features should not be enabled
• change system.enable_experimental to true in garak/resources/garak.core.yaml
• run python -m garak --help, there should be a message between the usage summary and options that experimental features are enabled

Question - would this feature be better off in a site config? I'm concerned about garak.core.yaml's value getting accidentally clobbered in a development commit

[jmartin-tech]

Question - would this feature be better off in a site config? I'm concerned about garak.core.yaml's value getting accidentally clobbered in a development commit

One option is to add garak.core.yaml to the .gitignore, changes to it could still committed they would just require an additional flag force adding any file changes to a commit.

I could see allowing this to be in garak.site.yaml as well, depending on what level of accessibility we want exposed. The banner combined with the serialized system config in the report log makes it clear if the option is turned on.

I am wondering if we should make this more of a feature flag set, maybe we should accept a list of experimental features to enable vs boolean value. That may be overkill for now though.

[leondz]

Alright. I think for now retaining the checks predicated on garak.core.yaml are more important than the odd mis-commit, so will proceed without a .gitignore. Site config is a great place for this flag but putting it there means changing the order of loading in a way that affects garak.cli processing, and I haven't taken a call on whether that's a good idea yet. So let's proceed as is