[SL-1631] Ensure predicate rendering is compatible with partition pruning directives across relevant engines

[tlento]

After all the other tasks associated with the overall predicate pushdown issue are complete, there will still be a number of cases where we will need to improve pruning triggers for certain engine types. Scenarios we may need to address with follow-ups include:

1. Cases where the partition filter granularity is different from the dimension itself and the query spec in such a way that our granularity adjustments bypass pruning - i.e., if we do date_trunc then partition pruning may not apply.
2. Cases where the partition filter column is tied to the agg_time_dimension but is not the agg_time_dimension itself (e.g., a PARTITION_LOAD_DATE might be mapped on to a daily granularity time field, and we'd want to render a separate filter expression)
3. Cases where there's a categorical partition that can be mapped from some other partition, like maybe a table is partitioned by REGION_CODE so any filter on COUNTRY can easily be made more efficient
4. Cases where a partition filter must always be provided, even if it is a partition IS NOT NULL constraint (like 3 above but where users want to group by country instead of pruning out input)

Some of these can be handled with more robust documentation around existing syntax and use of the is_partition flag on dimension columns, but others will likely require expanded support for partition specification in the semantic models themselves.

_{From SyncLinear.com | SL-1631}