FINERACT-2568: Remove unnecessary @Consumes annotations from GET and DELETE endpoints

[rhopman]

HTTP GET and DELETE operations typically do not accept a request body. However, many JAX-RS API resource classes in the codebase annotate these methods with @Consumes({ MediaType.APPLICATION_JSON }). This is misleading, as it implies the endpoint expects a request body when it does not. It can also result in unexpected 415 Unsupported Media Type responses on DELETE requests where the Content-Type header is not set.

There are two variants of this issue:

• Method-level: @Consumes is placed directly on @GET or @DELETE methods that have no body parameter.
• Class-level: @Consumes is placed on the class, which causes it to apply to all methods, including @GET and @DELETE methods that should not have it.

This PR:

• Removes @Consumes({ MediaType.APPLICATION_JSON }) from all @GET methods (they never accept a body).
• Removes @Consumes({ MediaType.APPLICATION_JSON }) from @DELETE methods that do not accept a body parameter.
• For class-level @Consumes annotations on classes that contain @GET or @DELETE methods: removes the class-level annotation and add @Consumes to each individual @POST / @PUT method that needs it.
• Removes unused Consumes and MediaType imports where applicable.
• Special case: EchoHeadersApiResource uses @Consumes({ MediaType.WILDCARD }) on a @GET intentionally and is therefor not modified.

Checklist

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.

[rhopman]

I realize this PR affects a large number of files, but since it's all the same issue, it didn't make sense to me to split it up. If this is not the preferred approach, please provide guidance.