Bugs and inconsistencies in logical operations

**Describe the bug**
In many cases, calling logical operations on complex numbers or Fractions leads to an error when it appears the value should be well defined; sometimes problems crop up with bigints or units as well

**To Reproduce**
All of the following fail, with various errors:
```
math.boolean(math.complex(1,1))
math.boolean(math.fraction(1,1))
math.boolean(100000000000000000000000n)
math.not(math.fraction(1,1))
math.and(math.fraction(1,1), math.fraction(1,1))
math.and(2, math.unit(1, 'g'))
math.evaluate('and(complex(1,1), complex(1,1))')) // math.and(math.complex(1,1), math.complex(1,1)) works!
math.or(math.fraction(1,1), math.fraction(1,1))
math.or(2, math.unit(1, 'g'))
math.evaluate('or(complex(1,1), complex(1,1))')) // ditto to above comment
math.xor(math.fraction(1,1), math.fraction(1,1))
math.xor(2, math.unit(1, 'g'))
// note math.evaluate('xor(complex(1,1), complex(1,1))') works.
```

**Discussion**
Note that I am not at all sure the list above is exhaustive of the problematic cases; it's very hard to make certain that a given test list is complete. Also, the fact that complex numbers fail with "and" and "or" in the expression parser but not in direct calls, and work ok with "xor" and "not" in both ways suggests that it has to do with short-circuiting, which only applies in the expression parser and only with "and" and "or".

Note that the logical expressions are defined by a series of implementations for different types. As a suggestion, I think it would be more robust and clearer to focus on the implementation of the `boolean()` conversion, and then just define the logical expressions by `any` arguments, converting the arguments to boolean as needed. If such a suggestion is taken, it would be essentially trivial to resolve #2483 at the same time.