Fall back to interpreted SpEL when compilation fails

[linghengqian]

• For Explore how to pre-compile SpEL expressions during AOT processing #29548 .
• Fall back to interpreted SpEL when compilation fails.
  • Previously, in a native environment—whenever the compilerMode was set to MIXED or IMMEDIATE (e.g., due to a spring.expression.compiler.mode configuration or the parsing of an expression requiring compilation)—SpelCompiler would attempt to call defineClass to generate CompiledExpression00001 upon the 100th evaluation (for MIXED) or the 2nd evaluation (for IMMEDIATE). GraalVM would then throw an UnsupportedFeatureError (which is an Error, whereas the legacy code only caught Exception types); this caused the entire evaluation process to crash, resulting in the process receiving a raw internal Graal error.
  • With the changes, the scenario plays out as follows: compilation failures are suppressed and tracked via failedAttempts, expressions fall back to interpreted execution with correct results (verified: 15 OK), and MIXED mode stops attempting compilation after 100 failures—aligning with the JVM behavior where non-compilable expressions fall back to the interpreter. IMMEDIATE mode also no longer leaks raw errors.
  • defineClass succeeds as expected on the JVM, so the fallback path is not triggered, and the full :spring-expression:test suite passes.
  • When using -H:+RuntimeClassLoading + Preserve, defineClass succeeds; empirical testing confirms that CompiledExpression00001 is indeed generated and the compiled execution path is taken, ensuring the fallback logic is not inadvertently triggered.