FBT001: Allow booleans used as values rather than flags

[arvidfm]

The post that originally inspired the FBT rules is concerned specifically with boolean flags that modify the behaviour of a function, and in that context they make a lot of sense in terms of readability, and I like to have the rules enabled for that reason. However, there are cases where the boolean is the value as opposed to a flag. You might encounter this for instance when dealing with functions for enabling options, where the meaning of the option is given by the function or object name itself, not the parameter: config.enable_fallback(False), self.is_running.set_value(True).

I think the linter already recognises this to some extent, as it already has exceptions for some functions that fall into this exact category (set_blocking, set_enabled, __setitem__ - albeit the first two for calls rather than definitions), but rather than adding individual exceptions, I think the rule could be relaxed in some clear-cut cases.

The most obvious case that I can think of where a bool is a value rather than a behaviour-modifying flag is when a function only takes a single positional-only parameter:

def enable_secret_mode(value: bool, /) -> None: # allow
    ...

class A:
    def set_running(self, value: bool, /) -> None: # allow - don't count self
        ...

One could also consider allowing defining functions that have multiple arguments, as long as the only positional(-only?) bool is the first argument. Or perhaps functions that only take positional-only arguments, and at most one of them is a boolean (think os.set_blocking).

This would also help when defining callbacks, where you can't use keyword-only parameters:

# can't use keyword-only parameter for callbacks
# no way to make the linter happy here
def my_callback(ok: bool, /) -> None:
    ....

# function takes a Callable[[bool], None]
do_thing("value", callback=my_callback)