This PR fixes a bug where column names that could be parsed as numbers (like the expression 1234) did not respond correctly to column ordering and would be the first column in a pivoted view:

This was due to the way that aggregates were parsed in the C++, which happened in three separate iterations:

1. Iterate through the columns array, and generate default aggregates for all columns not in the aggregate map
2. Iterate through the aggregate map (using the order generated by Object.keys()), and apply specified aggregates for all aggregate columns in the columns array
3. Generate aggregates for hidden sort columns.

I'm not sure exactly why I wrote the parsing logic the way that I did (in 2019, IIRC), but the issue it causes is simple: by ignore the column order when parsing the aggregates map, it assumes that the aggregates map can be iterated in the same order as columns.

However, in Javascript, in an object with a string key that is parsable as an integer (like "1234"), when iterating through the object using Object.keys(), the integer-parsable key is automatically moved to the front of the iteration order, and multiple integer-parsable keys are ordered in ascending order. More details here.

An example of this behavior is as follows:

This behavior does not seem to happen when the keys are parsable as floats ("4.5" and "5.55555", for example, remain in insertion order). Thus, the assumption that the aggregates map is ordered properly is broken, and so goes the column order. The fix is to rewrite the aggregate parsing logic to use the column order while iterating, and access the aggregates map through the column order instead of the order given by Object.keys().

I also removed the unimplemented and and or filters for boolean columns from the UI - though boolean columns are less common, selecting those would have caused an abort().