[BugFix] [RHEL/6] Fix audit_rules_time_stime OVAL check to return appropriate result also on 64-bit architecture

The existing ```audit_rules_time_stime``` OVAL check implementation is based on the observation that there isn't ```stime``` system call present in audit lookup table on 64-bit systems:
```
[root@localhost ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.6 (Santiago)
[root@localhost ~]# ausyscall i386 stime
stime              25
[root@localhost ~]# ausyscall x86_64 stime
Unknown syscall stime using x86_64 lookup table
```

This is correct. Though the logic in other audit OVAL check (e.g. ```audit_rules_time_adjtimex, audit_rules_time_settimeofday, audit_rules_dac_modification_chmod ...```) is as follows:
* when the system is 32-bit check just for -F arch=b32 version of a particular rule for given system call -S in /etc/audit/audit.rules,
* when the system is 64-bit check for presence of both (-F arch=b32 & -F arch=b64) versions of a particular rule for the given system call -S in /etc/audit/audit.rules.

Therefore in the case ```stime``` audit lookup table entry would be defined on 64-bit system, we would be checking for both (-F arch=b32 & -F arch=b64) versions of a particular rule for -S stime system call. But since it isn't we should be checking at least for -F arch=b32 case (for case a 32-bit application is running on 64-bit system that would be calling stime() system call).

But what current ```audit_rules_time_stime``` implementation is [doing](https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/checks/audit_rules_time_stime.xml) is as follows:
* the main check https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/checks/audit_rules_time_stime.xml#L12 is OR-ing of two subtests,
* the first subtest checks if the arch is 32-bit & if so if there's ```-F arch=b32 ... -S stime``` present in /etc/audit/audit.rules file -- https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/checks/audit_rules_time_stime.xml#L13
* the second subtest https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/checks/audit_rules_time_stime.xml#L19 when the system architecture is 64-bit effectively does nothing.

As a result this means that though this test will work on 32-bit architecture, it won't return proper results on 64-bit architecture (IOW it will always return PASS on 64-bit architecture even when ```-F arch=b32 ... -S stime``` audit rule isn't defined on 64-bit architecture).

But as already mentioned above even on 64-bit architecture it's possible to compile 32-bit application (e.g. via ```-m32``` compiler option) which would utilize the ```stime()``` system call & therefore should be audited (since as shown above in ```ausyscall``` command the 32-bit ```stime``` version is defined / supported also on 64-bit architecture). Sample output / audit entry created today this way:

```
[root@localhost ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.6 (Santiago)
[root@localhost ~]# uname -m
x86_64
[root@localhost ~]# ausearch -k audit_time_rules
...
----
time->Mon Dec  1 05:25:04 2014
type=SYSCALL msg=audit(1417429504.882:199): arch=40000003 syscall=25 success=yes exit=0 a0=ffed05d0 a1=ffed05d4 a2=466ff4 a3=0 items=0 ppid=3435 pid=3507 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="t_stime" exe="/root/t_stime" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="audit_time_rules"
```

where ```t_stime``` above is / was sample from:
  http://man7.org/tlpi/code/online/dist/time/t_stime.c.html

compiled as 32-bit application on 64-bit system.

Fix:
Therefore invert the logic of the check in the way it would:
* comply with the logic of other audit rules tests,
* check for presence of ```-F arch=b32 -S stime``` also on 64-bit architecture.

Testing report:
------------------
The proposed change has been tested on RHEL-6 for both (32-bit & 64-bit) architectures & works as expected (returns pass on 64-bit arch really only in case there's ```-F arch=b32 ... -S stime``` present in audit.rules).

Please review.

Thanks, Jan.