Re-order if blocks in RunMojo

Avoids loading a class if not needed, but doesn't seem to solve
any actual problems. I'll leave it in in case it helps later.

Testing gh-648
Extended documentation for applicaiton pid monitoring
Special case for deferred start based on Handler type

Fixes gh-673
Add support for .yaml file extensions

Apparently yaml.org prefers .yaml, but the internet seems
to be more aligned with .yml, so I guess we should support both
out of the box.

Fixes gh-675
Add spring.thymeleaf.contentType (defaults to HTML)

User can specify the content type in external properties now, optionally
ommitting the charset (since that is duplicated). If charset is not
appended by user Spring will do it.

Fixes gh-671
Expand Error Handling section in docs a bit

Fixes gh-513
Ensure that local file dependencies are packaged by the Gradle plugin

Prior to this commit, a dependency on a local file was not being
packaged by the Gradle plugin. This was a regression from the behaviour
in 0.5.0.M6 caused by the move to using a ResolvedConfiguration and
ResolvedArtifacts (4f677bec) to gain access to an artifact's type so
that non-jar artefacts could be filtered out. Since then, the approach
to filtering has been changed (38585bf3) and access to an artifact's
type is no longer needed.

This commit updates ProjectLibraries to restore its use of a
FileCollection rather than a ResolvedConfiguration when getting hold of
the files in a configuration. This means that the resulting jar will
now include dependencies that aren't resolved, such as those that are
provided as local files. The filtering that is applied to the files
is unaffected by this change and only files that are zip files will be
included.

Fixes #672
Minor documentation fixes
Add new thymeleaf property to docs

See gh-671
Import Spring Data release train BOM instead of individual modules.

The dependencies pom.xml now declares an import to the spring-data-releasetrain BOM pom.xml which in turn constraints version numbers for a dedicated release train release. This has the effect of users being able to upgrade to a certain release train by redeclaring the spring-data-releasetrain.version property to e.g. Dijkstra-M1. Individual modules can be upgraded by simply declaring the dependency in the desired version manually in a <dependencies /> or <dependencyManagement /> block.

Removed the explicit declaration for Spring HATEOAS as it is pulled in transitively by Spring Data REST anyway and thus makes sure it's in a compatible version.