refactor: restructure tests, add JVM based e2e tests

[paullatzelsperger]

WHAT

This PR introduces a test framework that leverages EDC's JUnit-based runtimes. That means, it is possible to run (and debug) multiple connector runtimes within the same JVM.

The legacy Cucumber-based business tests have been relocated into a subdirectory edc-tests/cucumber but left otherwise untouched.

As a third change, all "verification" tasks (spotless, checkstyle, all testing, sonar) have been moved into a separate GH Actions workflow to keep the individual workflows nice and succinct.

WHY

using in-mem tests is much faster and more efficient than spinning up a K8S cluster, it is also more stable and avoids timeouts and waiting.

FURTHER NOTES

• This PR does not replace all business tests with in-mem tests, rather, it lays the foundation and exemplarily shows how e2e tests can be done using just the JVM.

• We aim to add more of these JVM-based tests over time.

• most of the large changeset stems from moving the cucumber tests into a different directory

[ndr-brt]

I like this, a lot, because it will permit to apply the "test first" approach on the E2E layer too.
Regarding cucumber I'm not too much against it, I mean, it could be useful especially if we want to have the "non-technical" people to being aware of the behavior of the connector. Did that in the past, worked pretty well.

I also agree that's an additional layer of complexity for us, so, maybe let's take this decision through a decision record, so everyone could have their say

[paullatzelsperger]

Regarding cucumber I'm not too much against it, I mean, it could be useful especially if we want to have the "non-technical" people to being aware of the behavior of the connector. Did that in the past, worked pretty well.

This PR is about two things:

• show how the Multi-Runtime JUnit runner works
• Highlight why the "kill-multiple-birds-with-one-stone" approach isn't good and how it can be improved

So it is not necessarily about removing/replacing Cucumber. Personally I don't like Cucumber, because I find it very fragmented and hard to read (feature files, callbacks, util classes to parse the tables...), but that is besides the point and I'm sure we could make cucumber work with the in-mem runtime, if that's desired.

So yes, deciding whether or not to use Cucumber should absolutely go through a discussion and a decision record, but that was not the goal of this PR.