Spring Improve the fluency of the ResponseCreator API

• Added utility methods to DefaultResponseCreator

This enables the ability to fluently add single headers like you can already with the mock request specification APIs by chaining .header(name, value) repeatedly. This reduces code clutter within test cases.

Added the ability to add cookies as this simplifies tests that work with sessions.

Added the ability to override the character encoding used for setting a string body on a response, as this is useful when working in environments that do not automatically assume UTF-8, such as integrating with legacy applications from a new Spring one.

• Added unit tests for DefaultResponseCreator

These were already partially tested by the MockRestResponseCreator, but some existing calls prior to this PR were missing, and this was also an opportunity for me to directly test the changes I added.

• Added common response statuses to MockRestResponseCreators

It appears that a couple of the more commonly used HTTP status codes were missed out from the default methods in MockRestResponseCreators. The methods included are common enough that most test packs will probably have at least one case that uses one of these calls, so it enables keeping the fluent API tidy.

I added a couple of additional edge cases for common response statuses that will occur when working in cloud environments, such as AWS, CloudFlare, or using gateways such as Kong, where resillient applications should be able to respond to ratelimits, gateway errors, and gateway timeouts (which may occur if a remote service is down).

Added test cases for any changes made.

These changes allow for cases to be written like so:

server
    .expect(requestTo("/api/v1/users"))
    .andExpect(method(POST))
    .andExpect(header("Content-Type", APPLICATION_JSON_VALUE))
    .andExpect(header("Accept", APPLICATION_JSON_VALUE))
    .andExpect(jsonPath("$.name").value("Ashley"))
    .andExpect(jsonPath("$.username").value("ascopes"))
    .andExpect(jsonPath("$.password").value("12345"))
    .andRespond(withRequestConflict()
        .header("X-Request-ID", "12345")
        .header(HttpHeaders.PRAGMA, "no-cache")
        .cookie(ResponseCookie.from("anon-session-id", "12345").build())
        .body("Entity already exists", StandardCharsets.US_ASCII));

which should be more fluent and easy to read than what would be needed on the existing API:

HttpHeaders responseHeaders = new HttpHeaders();
responseHeaders.add("X-Request-ID", "12345");
responseHeaders.add(HttpHeaders.PRAGMA, "no-cache");
responseHeaders.add(HttpHeaders.SET_COOKIE, ResponseCookie.from("anon-session-id", "12345").build().toString());


server
    .expect(requestTo("/api/v1/users"))
    .andExpect(method(POST))
    .andExpect(header("Content-Type", APPLICATION_JSON_VALUE))
    .andExpect(header("Accept", APPLICATION_JSON_VALUE))
    .andExpect(jsonPath("$.name").value("Ashley"))
    .andExpect(jsonPath("$.username").value("ascopes"))
    .andExpect(jsonPath("$.password").value("12345"))
    .andRespond(withStatus(HttpStatus.CONFLICT)
        .headers(responseHeaders)
        .body("Entity already exists".getBytes(StandardCharsets.US_ASCII)));