feat: propagate Java stack traces from JVM upcalls into DataFusionError

[LantaoJin]

Which issue does this PR close?

• Closes Propagate Java stack traces from JVM upcalls into DataFusionError #55 .

Rationale for this change

When a Java-implemented upcall throws — scalar UDFs via JniBridge.invokeScalarUdf, table providers via JniBridge.invokeTableScan — the native side captures only class.getName() and getMessage() via jthrowable_to_string and surfaces it as DataFusionError::Execution(...). Since #81 routes that through to a typed ExecutionException, but the original Java stack trace is gone by then. A user whose UDF throws NullPointerException deep inside evaluate(...) sees:

ExecutionException: Java UDF 'my_func' threw java.lang.NullPointerException

with no way to find the failing line in their own code. The information exists; it's just discarded.

What changes are included in this PR?

This PR captures the Java-formatted trace (via Throwable.printStackTrace(PrintWriter) to a StringWriter) and appends it to the existing message. Verbosity is configurable per SessionContext so production paths that treat exception bodies as untrusted user input can opt out:

SessionContext.builder()
    .exceptionVerbosity(ExceptionVerbosity.MESSAGE)  // FULL (default), MESSAGE, NONE
    .build();

The default is FULL -- the issue's stated default -- so callers who don't touch the setter immediately gain stack traces with no API change.

Out of scope (called out in #55, deferred):

• Cause-chain attachment (the original Throwable as cause on the typed ExecutionException from feat: typed DataFusionException hierarchy across the JNI boundary #81). Needs a registry-handle for the throwable that survives the JNI return; complementary follow-up.

Are these changes tested?

Yes. 10 new tests in ExceptionVerbosityTest.

Are there any user-facing changes?

Yes, additive only -- default behaviour does change: the message string surfaced inside ExecutionException.getMessage() now includes the Java stack trace below the existing "Java UDF 'name' threw class: message" header. Callers that already only startsWith("Java UDF '...' threw")-style match keep working; anything stricter (an exact-equals on the message) would need the new MESSAGE verbosity to lock the pre-#55 format.

• New public type ExceptionVerbosity.
• New SessionContextBuilder.exceptionVerbosity(...) setter; default unchanged for callers that don't invoke it (their behaviour changes — they now get traces by default).