The SCRIPT_* family of variables can be accessed in phase 1 and returns invalid data

MODSEC-85: Here's a fragment from a debug log:

[4] Recipe: Invoking rule 9b001d8; [file "/opt/modsecurity/etc/rules.conf"] [line "6"].
[5] Rule 9b001d8: SecRule "SCRIPT_BASENAME|SCRIPT_FILENAME|SCRIPT_GID|SCRIPT_GROUPNAME|SCRIPT_MODE|SCRIPT_UID|SCRIPT_USERNAME" "@rx 222" "phase:1,log,auditlog,pass"
[4] Expanded "SCRIPT_BASENAME|SCRIPT_FILENAME|SCRIPT_GID|SCRIPT_GROUPNAME|SCRIPT_MODE|SCRIPT_UID|SCRIPT_USERNAME" to "SCRIPT_GID|SCRIPT_GROUPNAME|SCRIPT_MODE|SCRIPT_UID|SCRIPT_USERNAME".
[4] Transformation completed in 2 usec.
[4] Executing operator "rx" with param "222" against SCRIPT_GID.
[9] Target value: "0"
[4] Operator completed in 31 usec.
[4] Transformation completed in 2 usec.
[4] Executing operator "rx" with param "222" against SCRIPT_GROUPNAME.
[9] Target value: "root"
[4] Operator completed in 2 usec.
[4] Transformation completed in 2 usec.
[4] Executing operator "rx" with param "222" against SCRIPT_MODE.
[9] Target value: "0000"
[4] Operator completed in 2 usec.
[4] Transformation completed in 2 usec.
[4] Executing operator "rx" with param "222" against SCRIPT_UID.
[9] Target value: "0"
[4] Operator completed in 2 usec.
[4] Transformation completed in 2 usec.
[4] Executing operator "rx" with param "222" against SCRIPT_USERNAME.
[9] Target value: "root"
[4] Operator completed in 2 usec.
[4] Rule returned 0.

I think the correct thing to do in this case is for the variable to not-resolve and the rule not to run.

At the same time, a warning should be emitted that an attempt to access a variable that is not yet available was made.