Rename AssertableMockMvc to MvcTester and review assertions structure

[snicoll]

When we perform a request with MockMvc, we get a MvcResult that contains all the elements we need to assert that the processing of the request went well, such as:

• The request and the response
• What handler handled the request, and the ModelAndView if any
• A resolved exception if the processing failed and an exception handled handled it

AssertableMvcResult expands on the latter by providing the unresolved exception as well, rather than throwing a checked exception as MockMvc does.

This class can then be fed to AssertJ and we can then navigate on various pieces of the result:

assertThat(result).hasStatusOk()
assertThat(result).body()...
assertThat(result).headers()...
assertThat(result).cookies()...
assertThat(result).model()...
assertThat(result).handler()...

There are two things we'd like to explore here:

1. We want users to assign the result of perform so that they can run multiple asserts against the result. The name AssertableMvcResult is a bit off putting so we should consider renaming it
2. If we did then we should investigate the possiblity of exposing a MvcResult than extending MvcResult. This may allow us to navigate to more structured part of the result, such as:

assertThat(result.body())...
assertThat(result.headers())...

paging @philwebb and @simonbasle who helped me brainstorm on this.

[snicoll]

We've made quite a bit of progress here, focusing on the renaming bit of it. We came to the following proposal:

• Entry point named MockMvcTester (formerly known as AssertableMockMvc). After having considered several names and the fact that a reference to MockMvc and AssertJ can be desirable, we rather think that a pattern for the 2024 API review of things (à la *Client for production code) could be a way out. We think that *Tester could be such suffix. We still want to hint at MockMvc even if the actual implementation is mostly hidden (so it's rather a conceptual reference)
• Result MvcTestResult (formerly AssertableMvcResult) It doesn't extend from MvcResult but provides access to it. That's actually very important as folks upgrading to the new infrastructure may keep a reference to MvcResult that would have compiled but not giving any AssertJ capable support then.

Irrespective of this issue, we've reviewed of the API and found several shortcuts to be desirable, as well as avoid a double navigation for the body.

This proposal is available at https://github.com/snicoll/spring-framework/tree/mvctester-review