We have quite a number of actions that do nothing or are not very helpful, yet they waste time and have a possibility of randomly failing for uncontrollable reasons, not to say they make it impossible to understand which checks are important and which aren't. This PR addresses that problem, along with some minor improvements like naming.

The minimal number of jobs per PR went down from 29 to just 7

Unit test changes

We currently (as in before this PR) run unit tests with a matrix of linux/windows and java 8/11/17. Running the tests on both windows and linux is helpful, it has caught significant problems before.

However, running under different Java versions for every single commit is not that helpful. On the contrary, Java 17 tends to be very flaky, so we have to restart it all the time.

I've changed it so that we run:

• fast (smoke) tests for every commit in a PR, on linux/windows, but only under Java 11 (can change it to Java 8). Should be enough to catch the tests failing (especially since they are also additionally run in TeamCity)
• long and thorough tests for every commit in master, with the following matrix: linux/windows/macos and Java 8/11/17. They'll be run right after a PR has been merged, so hopefully we'll notice if it introduced any problems, and address it in time.

Long and thorough tests can be triggered manually for a specific branch, so we should have the possibility of validating big changes in advance (i.e if we see that it might break java 8 or 17).

Later on it'd be nice to randomize some aspects of the tests using something like github-actions-random-matrix. We'd be able to run random Java versions for PR tests, or shuffle platforms. This way, it'll still be quick, yet it should cover more cases overall as there are typically multiple commits in a PR.

Common changes

• Do not trigger a workflow if it doesn't need to be run. For instance, we only need to build/publish the examples if the examples/** directory was touched. Otherwise, they are using a stable version of Dokka and no other changes in code should affect them.
• Change workflow/job names to be shorter and more understandable, will help with visually inspecting it from the UI.
• Change workflow file names to be grouped together and convey the intention more.

I'll leave more detailed/context comments for individual changes/files