Propagate non-recoverable JSON conversion failures instead of demoting them to a generic 500

[apoupard]

Summary

GH-1429 (#ef533f377) already made convertNonMessageInputIfNecessary rethrow (rather than swallow) a JSON conversion failure when the request's Content-Type is JSON (failOnJsonError), fixing a misleading ClassCastException into a real Jackson exception in the logs. That's a great fix for the log message - but the rethrown exception is still wrapped as a plain IllegalStateException by convertInputPublisherIfNecessary, indistinguishable from any other conversion failure. Two consequences:

• It still resolves to a generic 500 for any web layer that doesn't parse exception messages to guess what went wrong.
• There's no way for a downstream consumer (a web framework's exception resolver, a custom @ControllerAdvice, an app's own error handler) to recognize "this converter deliberately, definitively rejected this input" without inspecting the message/cause chain.

This PR adds NonRecoverableConversionException, a narrow MessageConversionException subtype thrown only from the failOnJsonError path, and lets it propagate unwrapped through convertInputPublisherIfNecessary instead of being folded into the generic IllegalStateException bucket. Concretely, this lets an app register something like:

@ExceptionHandler(MessageConversionException.class)
ResponseEntity<?> handleBadInput(MessageConversionException ex) {
    return ResponseEntity.badRequest().body(...);
}

and get a real 400 for malformed input, instead of digging through IllegalStateException causes.

• No new dependency: MessageConversionException already lives in spring-messaging, a non-optional dependency of spring-cloud-function-context.
• No behavior change for any other exception type or code path - only the failOnJsonError branch's exception type changes.

Known follow-up (intentionally out of scope here)

A function declared as Function<Message<T>, R> (explicit Message-wrapped type) never reaches this path at all: convertInputMessageIfNecessary deliberately returns the original, unconverted message whenever the target type is itself Message<T> (to support legitimate no-conversion-needed cases like KafkaNull), which silently masks the same class of failure a different way. Functions declared over the plain payload type - the common case, and the only shape the new PojoFunctionIntegrationTests covers - are unaffected and fixed by this change. Happy to open a separate issue/PR for the Message<T> case if useful; it needs its own design discussion since the current fallback is deliberate, not an oversight.

Test plan

• SimpleFunctionRegistryTests#testReactivePojoFunctionPropagatesNonRecoverableConversionExceptionForMalformedJson (new) - removal-proofed: fails without the fix, passes with it.
• SimpleFunctionRegistryTests#testReactiveFunctionMessages (existing, valid-JSON case) - still green, confirming no behavior change on the success path.
• Full spring-cloud-function-context + spring-cloud-function-web suite: 199 tests, 0 failures, 0 errors (including the new PojoFunctionIntegrationTests).