[FEA] Unify distinct_count column/table APIs.

[bdice]

Is your feature request related to a problem? Please describe.
While reviewing #10030, I found that the column and table algorithms for distinct_count have completely different flags for null and NaN handling. The column API has null_policy (include/exclude) and nan_policy (NaN is/isn't null), while the table API has null_equality (nulls are equal/unequal).

This also applies to unordered_distinct_count, introduced in #10030.

Describe the solution you'd like
The distinct count APIs for column/table should use the same flags (meaning that all three flags should probably be available to both APIs). This would also allow the column API to be a pass-through implementation of the table API, with a table composed of only that column, rather than having two implementations (table, column).

[github-actions]

This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.

[github-actions]

This issue has been labeled inactive-90d due to no recent activity in the past 90 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed.

[divyegala]

Diving into this issue with @PointKernel led us to figure out this is more complex than it appears. In general, distinct and distinct_count should share the same configuration parameters, but as of now, they do not. The configuration parameters that appear in these APIs are:

1. null_policy : {EXCLUDE, INCLUDE}
2. nan_policy : {NAN_IS_NULL, NAN_IS_VALID}
3. null_equality : {EQUAL, UNEQUAL}
4. nan_equality : {ALL_EQUAL, UNEQUAL}

These 4 knobs all interplay with each other, and the right way to do this would be:

• Add 1 and 2 to the implementation of distinct, which currently exposes 3 and 4, while also using the new row comparators
• Write a common function inspired from distinct that builds a hash map, to be shared with distinct_count
• distinct uses the actual map and post-processes to build the result table, distinct_count just directly returns the size of the map
• This also helps update distinct_count to the new experimental comparators
• Start sharing tests/benchmarks between both these functions as they will essentially be sharing the same code path

[bdice]

@divyegala Yes, exactly! I agree this is a good plan for implementation.