Enhancing ServerLog handling of decode failures

Inspired by a discussion on the Community Forum: https://softwaremill.community/t/how-to-customize-logging-with-the-server-log-interceptor/361

We need better customization and safety in the default logging of decode failures in ServerLog.

Current Challenges:

1. Limited/inconvenient control of the logging level
   Users can't easily change the logging level for decode failures (e.g., from debug to warn) if a request is considered "handled and returning a 4xx response". Such errors go to doLogWhenHandled, which is not always intuitive, especially since there's an additional doLogAllDecodeFailures method and .logAllDecodeFailures(Boolean) flag that doesn't control such cases.
2. Customisation of error message
   The default message is preformatted as (link)

s"Request: ${showRequest(ctx.request)}, handled by: ${showEndpoint(
            ctx.endpoint
          )}${took(token)}; decode failure: ${ctx.failure}, on input: ${ctx.failingInput.show}; response: ${showResponse(response)}"

To change this, the user has to write their extension of DefaultServerLog and override decodeFailureHandled.

3. Safety of ${crx.failure}
   If the failure is of type DecodeFailure.Error, it has a field called original: String containing the full input body. In case of JSON decoding errors, it's the full JSON body, which in many cases shouldn't be printed due to its length and possibly sensitive information.

Start with server/core/src/main/scala/sttp/tapir/server/interceptor/log/ServerLog.scala, especially doLogWhenHandled, doLogAllDecodeFailures, logAllDecodeFailures, and decodeFailureHandled. Review DefaultServerLog and the linked Community Forum discussion first. Done means decode-failure logging level and message customization are clearer and full input bodies are not logged by default, with the relevant behavior covered by tests if present.