Is your feature request related to a problem? Please describe.

When using useSingleRequestParameter = true for WebClient and RestClient, the SingleReqestParameter model only has an AllArgsConstructor. Thus a caller has to do new RequestModel(param1, null, null, null, null) if the endpoint has 5 parameters but only the first one is relevant for the usecase.

It would be beneficial if the request model supported the same type of object instantiation as the general POJO model offers.

public static class DeletePetRequest {
    private String parameter1;
    private String parameter2;
    ...
 
    public DeletePetRequest() {}

    public DeletePetRequest(String parameter1, String parameter2, ...) {
        this.parameter1 = parameter1;
        ...
    }

    public DeletePetRequest parameter1(String parameter1) {
        this.parameter1 = parameter1;
    }

    public DeletePetRequest parameter2(String parameter2) {
        this.parameter2 = parameter2;
    }
    ...
}

This so that it is easy to only interact with the parameters that are relevant.

E.g., we generate an api-model for an api that has 5 parameters, for that I would with the current model need to state
new DeletePetRequest(param1, null, null, null, null).

Whereas with the POJO approach above we would only do
new DeletePetRequest().parameter1(param1).

This also makes it so that if the api adds new parameters then we are not forced to act on them (e.g., they add a sixth optional parameter, and I have to change the code from
new DeletePetRequest(param1, null, null, null, null) to new DeletePetRequest(param1, null, null, null, null, *null*).

Instead we do not need to do anything with the POJO approach. We only need to adjust it if it is the case that we want to utilize the new parameter. This would then be done with
new DeletePetRequest().parameter1(param1).*parameter6(param6)*.

My current idea is to build upon the functionality introduced with this PR, and introduce so that the "static" value would both affect the RestClient and the WebClient in the same way. This in an attempt to bring the two Spring-clients closer to each other. The goal in the long term being that "static" would become the go to solution since it will be a superset of "true".