MSQ window functions: Reject MVDs during window processing

[Akshat-Jain]

Description

This PR aims to reject MVDs when used as partition by columns during window function processing for MSQ engine.

Prior to this change, a MSQ query like the following was failing with ClassCastException:

select cityName, countryName, array_to_mv(array[1,length(cityName)]),
row_number() over (partition by  array_to_mv(array[1,length(cityName)]) order by countryName, cityName)
from wikipedia
where countryName in ('Austria', 'Republic of Korea') and cityName is not null
order by 1, 2, 3

This is a follow-up on #17002, where a similar thing was done for sql-native engine.

---

This PR has:

• been self-reviewed.
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[Akshat-Jain]

Based on offline discussion, we can wait for GlueingPartitioningOperator to be used, which would make it return a proper error message. So I'll close this PR.

[Akshat-Jain]

We had some queries like the following giving incorrect results, because the MVDs (List object) were getting converted to string:

As per offline discussion with @sreemanamala, have opened this PR and have added another check in RearrangedRowsAndColumns.

This is a temporary measure and would be removed once we have the GlueingPartitioningOperator approach as mentioned previously.

[kgyrtkirk]

I'm not sure how frequently people will run into this - but the updates which supposed to be made to this part will make this check as well go away.
Let's have it for now

[cryptoe]

Since we require this check for druid 31, we can live with this "hackery". Once #17038 gets merged, please remove this check.
cc @Akshat-Jain