Refactor WindowOperatorQueryKit to use WindowStage class for representing different window stages

[Akshat-Jain]

Description

This PR refactors WindowOperatorQueryKit to use a new class WindowStage to represent the different window stages. Previously we were dealing with List<OperatorFactory> or List<List<OperatorFactory>>, and doing a bunch of instanceof checks, so this refactor makes it much more readable and cleaner.

This PR does not have any functional change.

---

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]

@kgyrtkirk Thank you for the review!

I was wondering if it makes sense to get #17038 merged first, and then resolve conflicts on this PR, instead of the other way round? Plus this PR is much smaller than the other one, so it would allow us to iterate faster on this after getting the other PR merged.

If we try to merge this PR first, a lot of this PR's logic would have to be re-worked when resolving conflicts on the GlueingPartitioningOperator PR. That PR is already huge, it would be unnecessary to re-work this PR's logic there.

Thoughts?

[kgyrtkirk]

we will merge the PR which is ready first

I've suggested to open this from that pr here - so I think the natural order is to have this one finished first