This customizer allows securing source code by controlling what code constructs are allowed. For example, if you only
want to allow arithmetic operations in a groovy shell, you can configure this customizer to restrict package imports,
method calls and so on.

Most of the securization options found in this class work with either blacklist or whitelist. This means that, for a
single option, you can set a whitelist OR a blacklist, but not both. You can mix whitelist/blacklist strategies for
different options. For example, you can have import whitelist and tokens blacklist.

The recommanded way of securing shells is to use whitelists because it is guaranteed that future features of the
Groovy language won't be allowed by defaut. Using blacklists, you can limit the features of the languages by opting
out, but new language features would require you to update your configuration.

If you set neither a whitelist nor a blacklist, then everything is authorized.

Combinations of import and star imports constraints are authorized as long as you use the same type of list for both.
For example, you may use an import whitelist and a star import whitelist together, but you cannot use an import white
list with a star import blacklist. static imports are handled separately, meaning that blacklisting an import
does not prevent from using a static import.

isIndirectImportCheckEnabled

setIndirectImportCheckEnabled

Set this option to true if you want your import rules to be checked against every class node. This means that if
someone uses a fully qualified class name, then it will also be checked against the import rules, preventing, for
example, instantiation of classes without imports thanks to FQCN.

getReceiversBlackList

setReceiversBlackList

Sets the list of classes which deny method calls.
Please note that since Groovy is a dynamic language, and
this class performs a static type check, it will be reletively
simple to bypass any blacklist unless the receivers blacklist contains, at
a minimum, Object, Script, GroovyShell, and Eval. Additionally,
it is necessary to also blacklist MethodPointerExpression in the
expressions blacklist for the receivers blacklist to function
as a security check.