Short-circuit evaluation for logical operators

__Proposal:__
In C and many other languages, there is short-circuit evaluation of logical operators from left to right.

For example, you could do something to the extent of:

```
if (p != NULL && *p == 'X') {
...
}
```

This always works because the second comparison will only be evaluated when the first is already true, thus even when p is NULL, there will never be an out-of-range exception.

In Flux with influxdb 2.6.1, this is not the case. I had a query like this:

```
from(bucket: "${Bucket}")
|> range(start: -1m)
|> filter(fn: (r) => r["_measurement"] == "system")
|> filter(fn: (r) => contains(value: r["object"], set: ["qemu","lxc"]))
|> filter(fn: (r) => r["nodename"] == "${server}")
|> last()
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> keep(columns: ["object", "vmid", "host", "status", "uptime", "cpu", "mem", "maxmem", "template"])
|> sort(columns: ["vmid"], desc: false)
|> sort(columns: ["object"], desc: true)
```

When I tried to filter out lines with a specific value for the 'template' field, it would not work:

```
|> filter(fn: (r) => r["_field"] == "template" and r["_value"] == 1)
```

The error was:

```
invalid: runtime error @5:6-5:71: filter: cannot compile @ 5:17-5:70: unsupported binary expression string == int
```

When I changed the comparison to:

```
|> filter(fn: (r) => r["_field"] == "template" and r["_value"] == true)
```

the error changed to:

```
invalid: runtime error @5:6-5:74: filter: cannot compile @ 5:17-5:73: unsupported binary expression float == bool
```

This was because there were other fields that had another type (namely string and float). With short-circuiting, the expression should never have been evaluated for _field <> "template", in which case the value always has the same type.

__Short summary of the feature.__

Short circuit evaluation of boolean expressions.

__Current behavior:__

Every part of a boolean expression is evaluated independently of its predecessors.

__Desired behavior:__

The "and" and "or" operators should work like in C and many other languages. This would also help performance to a certain extent.

__Alternatives considered:__

None.

__Use case:__

See description above, I tried to filter by specific values.

Start by tracing Flux boolean expression handling and the filter evaluation described in the examples. Verify how the `and` and `or` operators currently evaluate both sides, then define behavior where the right side is skipped when the left side determines the result. Done means the provided filters avoid incompatible comparisons through left-to-right short-circuit evaluation.

Written by the indexing model from the issue text.