HHH-19202 Fix array_intersects function with array parameters

[JiHunparkkk]

Problem

When using array_intersects with a parameterized array query like:

em.createQuery("from EntityWithArrays e where array_intersects(e.theArray, :array)", EntityWithArrays.class)
    .setParameter("array", new String[]{"abc", "xyz"})

H2 database throws: JdbcSQLSyntaxErrorException: Unknown data type: "?3"

Root Cause

1. AbstractArrayIntersectsFunction used a generic StandardFunctionArgumentTypeResolvers.byArgument() which didn't properly infer array types bidirectionally
2. H2ArrayIntersectsFunction rendered parameters with accept(walker) instead of walker.render(..., NO_PLAIN_PARAMETER), causing H2's array_get() function to receive untyped parameters

Solution

1. Created ArrayIntersectsArgumentTypeResolver for bidirectional type inference between the two array arguments
2. Modified H2ArrayIntersectsFunction to use SqlAstNodeRenderingMode.NO_PLAIN_PARAMETER which renders parameters as CAST(? AS ARRAY_TYPE) instead of plain ?

Changes

• AbstractArrayIntersectsFunction.java - Use ArrayIntersectsArgumentTypeResolver.INSTANCE
• ArrayIntersectsArgumentTypeResolver.java - New resolver for bidirectional array type inference
• H2ArrayIntersectsFunction.java - Use NO_PLAIN_PARAMETER rendering mode for array_get() calls
• ArrayIntersectsTest.java - Add testArrayParameter() test case"

Test

Test case referenced from #9798

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

https://hibernate.atlassian.net/browse/HHH-19202

---

Please make sure that the following tasks are completed:
Tasks specific to HHH-19202 (Bug):

• Add test reproducing the bug
• Add entries as relevant to migration-guide.adoc OR check there are no breaking changes

[mbellade]

Thank you @JiHunparkkk, but I don't see a need for the custom argument type resolver - the existing implementation should already infer the parameter type from the entity path expression.

#11679 was also opened for this bug, and I think the solution is cleaner - I'll close this one in favor of that.

[JiHunparkkk]

Thanks for the review and explanation!

I see your point, and I agree that the approach in #11679 is cleaner and avoids the need for a custom argument type resolver.
Happy to close this one in favor of that.

Thanks again!