Fix rule evaluation for list options

[imbriaco]

Previously, the rule evaluator would coerce list type options into a string before evaluating the comparisons contained within the right-hand-side of an in operation. For example:

String Comparison:

Example Command: my-command --list foo --list bar --list baz
Rule: when command is my-command with option[list] in [ foo ] allow
Evaluates: "foobarbaz" == "foo"

This would only return the expected result if the list option only had a single value.

Regex Match:

Example Command: my-command --list foo --list bar --list baz
Rule: when command is my-command with option[list] in [ /foo/ ] allow
Evaluates: Regex.match?(~r/foo/, "foobarbaz")

The Regex version of this would usually return the expected results, though there could be unexpected behavior which would also affect the string comparison version.

Edge Cases, Oh My:

For instance, the following command and rule would evaluate to true which is unlikely to be the expected behavior.

Example Command: my-command --list f --list oo
Rule: when command is my-command with option[list] in [ foo ] allow
Evaluates: "foo" == "foo"

This PR cases the in expression to be evaluated against each item in the option rather than on a stringified version of the option.

[kevsmith]

👍