Add explicit truthiness semantics for constant BooleanExpressions

[kevinjqliu]

While this PR can use expression negation via __invert__, I think it may be worth supporting Python truthiness for the constant expressions in a follow-up:

class AlwaysTrue:
    def __bool__(self) -> bool:
        return True

class AlwaysFalse:
    def __bool__(self) -> bool:
        return False

That would make patterns like this behave intuitively:

        if not self.visit_starts_with(term, literal):
            return AlwaysTrue()

When adding this, we should also be careful that Python truthiness is for control flow, not expression construction: not expr returns a Python bool, while ~expr returns a negated BooleanExpression. It would probably be safest for non-constant BooleanExpression.__bool__ to raise, with only AlwaysTrue and AlwaysFalse overriding it. The follow-up should also audit optional-expression checks like expr or AlwaysTrue() and REST residual/filter handling so explicit AlwaysFalse() values are not treated as missing.

Originally posted by @kevinjqliu in #3503 (comment)

[rambleraptor]

This scares me bit truthfully (pun not intended).

It seems like we're trying to get to a place where certain Boolean operators act on the object's presence, while others act on their name. Users shouldn't have to have an understanding of the internals of BooleanExpression to understand how the Python Boolean operators work.

This only is really a problem for AlwaysFalse()