Improve the fluency of the ResponseCreator API

[ascopes]

• 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)));