[IMPROVEMENT] AkkaHttpServerInterpreter should be extendable

AkkaHttpServerInterpreter is implemented as a trait, and it seems very logical that a consumer might want to implement a custom instance of this in order to meet their needs. For example, in our use case, we want to wrap all EP routes with a directive for logging and a custom directive for handling open tracing support. Instead of having to wrap this in a custom class, it would seem that the proper way to do this would be to provide a custom AkkaHttpServerInterpreter that would generate the Route appropriately. While the implementation of AkkaHttpServerInterpreter is pretty light, it makes use of several private classes that I think should be usable: AkkaServerRequest, AkkaRequestBody, and AkkaToResponseBody.

I would maybe like to make see something like this:

val myServerInterpreter: AkkaHttpServerInterpreter = AkkaHttpServerInterpreter.instance {
  case (interpreter, severRequest, serverEndpoints) => // Existing implementation  
    onSuccess(interpreter(serverRequest, ses)) {
      case None           => reject
      case Some(response) => serverResponseToAkka(response)
    }
}

or even

val myServerInterpreter: AkkaHttpServerInterpreter = AkkaHttpServerInterpreter.instance {
  responseMonad: F[Option[ServerResponse[B]]] =>
    onSuccess(responseMonad) {
      case None           => reject
      case Some(response) => serverResponseToAkka(response)
    }
}

Which would then be used as expected:

val route: Route = myServerInterpreter.toRoute(myServerEndpoints)

This would allow standard route directives to be implemented and interpreted as expected instead of having to wrap Tapir's models in redundant custom ones. Being able to provide custom converters and interpreter construction logic might also be useful.

Start by reading the AkkaHttpServerInterpreter trait and the private AkkaServerRequest, AkkaRequestBody, and AkkaToResponseBody classes. Compare the proposed instance and response-handling designs with the existing toRoute usage. Done means a consumer can provide custom route directives or interpreter construction logic without redundant wrapper models, with the resulting Route behavior verified.