Adding expectations for the rendered output reveals annother misconception

* Added Jsoup to check some expectations regarding the rendered pages.
* This revealed another misconception about the behaviour of MockMvc.
* The MockMvc-environment does not render a full version of the White Label
  ErrorPage, that Spring-Boot shows for uncaught exceptions.

Refined the test: @ParameterizedTest adds no additional insight here

* The parameterized tests only test the difference between an empty and an
  non-empty Optional.
* The actual number is meaningless, because the business logic is mocked
  away anyway!
* Hence, the parameterized version only tests the correctness of our mocking:
  The test could only fail, if we make a mistake in the setup of the
  expectations, not in the code under test!
* Also splitted up some test-cases more logically.

Further refined the example: Simplified the setup

* Goal: Do not rely on knowledge about Thymeleaf
* Goal: Separate MVC (controller) from business logic (service)
* Introduced an ExampleService
* The service checks the answer for
  The Ultimate Question Of Life, The Universe And Everything
* Requests without any answer are tolarated, so that the page with the
  question can be rendered
* Only numbers (Integer) are allowed as answer.
* Negative numbers are not allowed as answers: the service answers with an
  empty Optional.
* The view contains a bug, that results in a 503 for negative answers:
  Optional.get() is called, regardless of the state of the Optional

* The view renders the question, if no answer is specified (initial request!)
* If a valid request is specified, the answer and the outcome is rendered
* If an invalid request (negative number!) is specified, the view generates
  an exception, because it tries to resolve the Optional anyway

Refined the example, to clearify the intent

* Removed unnecessary Annotation from test
* Renamed and pimped up the example templates
* Splitted up the test in separate units
* Remapped the controller to the root of the web-context
* Switched to @WebMvcTest, to load only the controller-layer

Renamed and repackaged the example for the blog-article

Initial Commit: Spring-Boot-Project, that pinns down a bug in a test-case

* I stumbled accros the unexpected behaviour of Springs MockMvc in a
  test-case for one of my projects.
* This version pinned down the unexpected behaviour explicitly.