Return booleans from expression comparisons, allow for vectors to be defined in expressions

[sc1f]

This PR rewrites a good amount of our ExprTk integration so that comparisons such as ==, <, and, or etc. return boolean columns instead of floats. Originally, all comparisons returned floats because ExprTk treated booleans as the number 0 or 1, and passed them into the t_tscalar constructor as ints and not booleans. Because scalar comparison between different types is not possible, functions had to return float values in order for conditionals to work.

In this branch, I've added explicit specializations for more of ExprTk's processing code so that operators and conditional evaluators always return boolean scalars. In combination with the UI tweaks in #1547, expressions now can be easily used as filters on the dataset:

This also works well for defining ranges using inrange, such as a date range:

Finally, users can define vectors inside expressions and use them/return scalars from the vector at will:

Vectors specifically enable a massive amount of features, including functions such as find and split which need to return more than one value. A find(string, regex, output_vector) function, for example, will store its output of start_idx, end_idx in output_vector, and the user can then create a substring from those indices using substr(output[0], output[1]).

The values True and False have been added, replacing the values true and false (without capital letters), which resolved to the numbers 1 and 0. True and False, meanwhile, resolve to true and false boolean scalars, which means they can be used in comparisons against other booleans, whereas the old values will now result in a syntax error.

Finally, a boolean function has been added to cast a scalar or column of any type into a boolean column, returning True if a value is set (including "falsy" values such as 0 and ""), and False for nulls.

Numerous tests have been added, as always.

[texodus]

Do these need to be macros? They impair readability here.

At minimum, they should take sym_table as argument and not name-capture as they do now.

[texodus]

Looks good! Thanks for the PR!

I've added a step to the pre-processor to convert true and false to True and False symbols, respectively, as I felt the error message especially when using these was unclear ("Syntax Error"). However, like #1550, the regex for these is not correct - it does not escape quotations, e.g.. This is far from the only incorrect behavior in the pre-processor however, so I've elected to just allow this rare corner case in the interest of fixing the larger issue (booleans). We really do need to fix the pre-processor in a future PR however, starting by re-factoring it to wasm so it need not be re-implemented for multiple languages.