LDEV-6226 fix cross-classloader method resolution and type conversion

[zspitzer]

Summary

Port of #2772 (6.2) to 7.0.

Fixes intermittent NoSuchMethodException when calling Java methods from CFML after a classloader swap. Affects both OSGi bundle refreshes and JavaSettings classloader flushes (reinit, idle eviction, systemCacheClear).

• https://luceeserver.atlassian.net/browse/LDEV-6226
• https://dev.lucee.org/t/lucee-6-2-6-19-rc-available-for-testing/17178/6

Root Cause

When a Java object is persisted in a long-lived scope (e.g. variables.sfnClient) and its classloader is replaced, the persisted object's class is from the old classloader while newly created arguments come from the new classloader. Same class name, different classloader = strict class identity checks fail.

Two code paths affected:

1. Clazz.getMethod() / getConstructor() Phase 1 - uses Class.isAssignableFrom() for type matching, fails cross-classloader
2. Reflector.like() - used by _convert() in Phase 2 method resolution, delegates to isInstaneOf(src, trg, true) which also does strict identity. With overloaded methods this silently picks the wrong overload (e.g. Object instead of the typed parameter).

Fix

Clazz.java: Phase 1 - try isAssignableFrom first, fall back to Reflector.isInstaneOf(argClass, paramClass, false) for name-based comparison.

Reflector.java: like() - try identity, then isAssignableFrom, then isInstaneOf(src, trg, false) for cross-classloader name-based matching.

Test plan

• LDEV6226.cfc - 6 tests, all passing