This turned out to be a low-hanging fruit. With this change, these two
expression behave the same as far as the rule indexer is concerned:

    input.foo != false # this worked before
    input.foo          # now works, too!

Under the hood, expressions like `input.foo` are handled as if it was
written as `x = input.foo` for a synthetic variable. That way, it's
handled the same -- 100% the same, so we're not looking at the actual
value of `input.foo` in the rule index lookup, we're just selecting the
rules that use it (and omit the ones that don't). The actual FAIL that
may happen in evaluation if `input.foo` is `false` will just happen as
it always has, and give up on that subtree for evaluation.

Also similar to `input.foo != false`, there is no support with `not` or
`with` in the rule index.

Note that we don't handle function arguments in the same way:

If you have a function (with some more rule bodies so that RI matters),

```rego
foo(a, b) if {
  a > 1
  b == 200
}
```

and the evaluator does a lookup of `foo(2, 100)`, it will not evaluate
that body -- because `b` is used in the indexer with value `100`.

Now, if that was a naked expression,

```rego
foo(a, b) if {
  a > 1
  b
}
```

it will not be handled any different with this change: It's a function
argument, so it cannot be undefined. There's no point in using the rule
index to reference this function body for "b is defined" -- it always is
if we're calling the function.


Previously mentioned in open-policy-agent#642 (comment).

Signed-off-by: Stephan Renatus <[email protected]>