feat(confmanager): Added ZMS.input.exec.restrict

[cmeier76]

On discussing and reverting #430 (comment) we suggest these further actions - but we are unsure whether it has unintended consequences. What do you think...?! cc/ @OscarMeier

[cmeier76]

@drfho & @OscarMeier As discussed earlier today I introduced a new conf property ZMS.keywords.prevent in e02b822

It preserves handling in standard.dt_exec (conf property with restricted keywords are optional) and it is required to use the new standard.get_env wrapper method (setting of conf property is mandatory for the given context).

[drfho]

Hi, according to "Restricted Python" we may choose a similar term, because the approach has a similar goal: preventing code executions by defining restricted function names. Moreover there is a term "input" qualifying confproperties, dealing with user-entries.
Putting it together the terminology might be:

1. ZMS.input.exec.restrict
2. check_restricted_inputs(context, value, can_ignore)

The param 'can_ignore' is a doubled negation? ignore restriction vs. forcing the restriction? If the confprop ist not available, its restriction shall be forced, right? Why not give a default here, like check_restricted_inputs(context, value, force_restriction=False)

[drfho]

LGTM

Hint:
The new error may have devastating effects on the content stream. So the standard-template of the concerned object may need some exeption handling for giving a polite feedback ;-)

[cmeier76]

Hint: The new error may have devastating effects on the content stream. So the standard-template of the concerned object may need some exeption handling for giving a polite feedback ;-)

@drfho I would have expected the message and traceback from the raise exception - as seen in my tests: