[jaxrs] WebApplicationException to handle error response codes

Description

as already mentioned here by @Tillerino,

a much cleaner way of handling response codes in JAX-RS is using WebApplicationException

This way, the service implementation can exploit the marshalling for DTO classes.
For example, instead of:

@Override
public Response getMyExamples(SecurityContext securityContext) throws NotFoundException {
        // do some magic!
        return Response.ok().entity(new ApiResponseMessage(ApiResponseMessage.OK, "magic!")).build();
}

we can generate:

@Override
public List<MyExample> getMyExamples(SecurityContext securityContext) 
       throws  javax.ws.rs.WebApplicationException {
        // TODO do some magic! 
        throw new InternalServerErrorException("Not yet Implemented");
        // throw new javax.ws.rs.BadRequestException( "Invalid parameter value" );
        // throw new javax.ws.rs.NotFoundException( "MyExample not found" );
    }

Advantages:

• the return type is a plain java object. Actually it is already an autogenerated class by swagger codegen.
  no needs to build an ApiResponseMessage
• the error messages are suggested in comments together with elegant code to generate the error. the developer does not need to remember (or check) what is written in the OpenAPI spec.
• it is still jaxrs compliant

Related issues/PRs

already mentioned here by @Tillerino. issue #4509

Suggest a fix/enhancement

I'm actually working on this improvement. I can provide a PR:
The source code modification affects the AbstractJavaJAXRSServerCodegen, so this enables more than one jaxrs implementation to adopt the described structure.
However I'm working only on the jaxrs/jersey template and finally comes my question:

It is better to create a new template or modify the existing one?
If it is better to create a new tempate a I've some question: how to create a new one? what name?

Start by reading AbstractJavaJAXRSServerCodegen and comparing the existing jaxrs/jersey template with the proposed WebApplicationException-based output. Determine whether the existing template can support plain DTO return types and suggested JAX-RS exceptions, or whether a separate template is needed. Done means the chosen JAX-RS generation path produces compliant methods with the described error-handling comments and exception structure.