Support for polars Categorical datatype

[AndrewZehrQC]

Currently, pipedag fails when trying to materialize a polars table with Categorical types

[windiana42]

@AndrewZehrQC the question is what do you expect for materialization in case of categorical. The ideal solution would be to preserve the speed of categoricals in SQL. This would mean to store it as an integer column and then write an additional table that can be used to map the integers back to strings. Dematerialization should automatically detect the additional table and map the data back to categoricals on the python side. @finn-rudolph at some point it might be nice if pydiverse transform could deal with such categorical columns within SQL.

@AndrewZehrQC I could imagine you rather had the quick bug fix in mind which would be converting a categorical column to a string column during materialization. It could be possible to also speed up this process by first writing very short strings per categorical and then send performing the replacement with the long strings in SQL. However, since the solution above would be so much nicer, I wouldn't invest too much on this transfer time speedup.

[windiana42]

When supporting categoricals in SQL, it might be convenient to dematerialize not just an sa.Table as sa.Alias, but to dematerialize already a join query with the categorical resolution. Even though sqlalchemy does support getting columns from a join query via prefixed column names, I actually don't like this option too much. However, returning a tuple with multiple elements (main table, dictionary of categorical table aliases) might yield quite a complex user interface. With pydiverse transform we can make this super nice giving you even access to both the joined string and the category integer.