Added a layout based on Bootstrap-4.x with the help of webjars

* The templates refer to bootstrapcnd.com directly
* The production-version uses webjars, to embed the CSS in the app

Added a customized error-page

Added an integration-test that tests the exception-handling

* The integration-test uses WebTestClient to test the exception-handling
* Since this is a real integration-test, the exception-handling behave
  exactly the same way
* The test-setup with the WebTestClient needs an additional dependency, to
  work correctly - without it, the WebTestClient-Bean would not be
  intanciated
* The added test ExceptionHandlingApplicationIT tests exaclty the same
  stuff, as ExceptionHandlingApplicationTest - this is no good test-design,
  but it serves the intention, to compare the two approaches
* Since Spring-Boot configures the surefire-maven-plugin to ignore all
  tests, that end with IT, the failsafe-maven-plugin has to be added to
  automatically fire the new test - remember: you have to call "mvn verify"
  to fire IT

Added a working @ExceptionHandler

* Both handlers resolve the handled exception as 503 Internal Server Error
  and are using the template "error/503", which was extended to print a
  message, that the reported exception was catched and handled.
* If one starts the app, it is clearly visible, that the mechanism only
  works for exceptions, that are thrown in the context of the controller.
* Also added a test-case, that shows, that MockMvc shows the expected
  behaviour for exceptions, that are thrown inside the container.

Fixed non-working test-cases

Added spring-boot-devtools

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.