The Spring Boot 2.x migration will be a rewrite, so we will keep the
previous code next to the new version while migrating. Since this will
need a different set of Maven dependencies, the complete management POMs
will be replicated into a `legacy/` subfolder.

To not collide accidentally while refactoring, the complete
autoconfigure and actuator code in the `legacy/` folder has now a
`.legacy` inserted into the package hierarchy.

The next release will be a REAL major version. This change was brought
to you by:

```
$ ./mvnw versions:set -DnewVersion=2.0.0-SNAPSHOT -DprocessAllModules=true
```

Multiple parts of CoffeeNet contribute UI/UX components to the final
application. This abstraction allows to write these in a
technology-agnostic way.

To enable more CoffeeNet autoconfiguration possibilities, we need to
hook into the process of defining global `SecurityConfigurer` beans,
that are applied to instances of `WebSecurityConfigurerAdapter`.

This makes use of the feature from the previous commit, to automatically
configure features on instances of `WebSecurityConfigurerAdapter`, if
certain conditions are met. In this case, we auto-enable OAuth2.

Mirroring `SecurityAutoConfiguration` from Spring Boot, this class will
be used only for servlet based environments. We will later add a
reactive variant.

In the previous CoffeeNet iteration a profile for the currently logged
in user could be retrieved via an exposed service. Most of the time this
feature is needed for frontend work. Therefore we implement this
reworked implementation via the Spring mechanism of a
`HandlerMethodArgumentResolver`.

This commit adds the needed auto-configuration as also an implementation
for OAuth2/OIDC.

The existing implementation was not exactly correct, having missing
edge cases for equals/hashCode as also being prone to modification of
the original map, when reusing the same builder.

Since the whole profile concept is actually tied to authenticated users
and CoffeeNet is meant to be used in the web context only, we can better
infer, if profile support is needed, when depending on the security
filter chain.

Having a fallback implementation of profile mapper is a good idea, to
make CoffeeNetProfile available, even when authentication was made by a
currently not supported variant. This is especially true for the
development case, where working on an application doesn't necessarily
makes OAuth2 providers available.

Migrate CoffeeNet Security to OIDC

This recreates the previous adaptions to the Maven based with the Gradle
build integrated into `master` branch.

Since in Gradle we don't have the limition of a Maven multi module build
that every project has to be a unique artifact, we can remove the
`-legacy` postfix from all the projects in the `legacy/` subfolder.

While we didn't touch the previous discovery mechanism in the rewrite
yet, the starter involved was using the old Dalston.SR5 release of
Spring Cloud, pulling in some undesirable dependencies in the process.

We simply upgrade to current Hoxton.SR3 and use the correct dependency.

Since the `PrincipalCoffeeNetProfileMapper` is explicitly intended to
work with implementation of `java.security.Principal` we can reflect
this in the method signature.

The `DefaultCoffeeNetProfile` is a default implementation, that cannot
instantiated or subclassed and is only constructable by a builder. We
move the builder to the actual `CoffeeNetProfile` interface and hide
the default implementation at the package level.

Since we want to encourage usage of JUnit 5 all across the CoffeeNet
projects, we exclude it by default from the transitive dependencies of
`spring-boot-starter-test`. This way JUnit 4 annotations and classes
will not be available.

Since we may want to serialize the domain interfaces to JSON, we should
add consistent naming for the resulting JSON keys emitted.

… classpath

In prepartion for WebFlux support, we move the configuration for the
`CoffeeNetProfileMapper` into the parent package.

This commit adds auto-configuration for WebFlux based applications in
the same manner, that servlet based applications are instrumented.
Specifically it adds auto-configuration for OAuth2 authentication on all
WebFlux `ServerHttpSecurity` instances and the method argument
resolution of `CoffeeNetProfile` for those applications.

Enable support for WebFlux in CoffeeNet instrumentation

To ease prototyping features with the rewrite we start publishing the
`spring-2-rewrite` branch to Sonatype OSS snapshot repository too.

Instead of listing all `coffeenet-starter*` dependencies manually, we
simply can add all starter artifacts by iterating over existing
subprojects and adding those who match the name pattern.

We ensure in our build configuration to produce Java 8+ compatible
artifacts. But Sonaqube is complaining if the Java version used for the
build is 1.8, so we switch the build to actually use Java 11.

Spring Cloud Hoxton.SR5+ are now only supported on Spring Boot 2.3+.