chore: use start-stack command for e2e tests, replace Makefile by poetry-exec-plugin (DEV-1597)

[jnussbaum]

resolves DEV-1597

• make docs/index.md more suitable for PyPI landing page
• include "anything" onto+data in start-stack command, so that this command can be used for the e2e tests
• replace Makefile by poetry-exec-plugin
• first time using Semantic Line Breaks (https://sembr.org/)
• remove daily tests, because now, the e2e tests don't run any more with the daily-changing main branch of DSP-API, but always with the same Docker images
• tidy up all YML GitHub Actions files, modify/remove some of the names

[irinaschubert]

LGTM

[BalduinLandolt]

looks good over all, just some minor suggestions.
To fix the failing tests, I think you can just use the full admin (and maybe permissions) data turtle files, instead of the minimal ones.

[BalduinLandolt]

you could also look into the poetry exec plugin to automate poetry workflows, which might spare you even more of the makefile

[BalduinLandolt]

(for a discussion, see here python-poetry/poetry#241)

[jnussbaum]

Good idea, it would be cool to get rid of the Makefile, esp. because there are only 2 commands left in it, each a 1-liner. But I'm a bit reluctant using a plugin which is still pre-1.0... What do you think?

[BalduinLandolt]

I think it would be worth trying, even if it's only to see how well it works. In any case, it would be easy enough to revert back to having the make file (and if it's only two one-liners, you could just as well put them into the readme and execute them manually).
Speaking of those two commands: in the make clean command, are most of them still needed? I would guess that both mkdocs (for the docs) and poetry (for building) take care of removing old files pretty well.

[jnussbaum]

OK, done :-)
There is only one exec-script remaining, and that one is only used by me. This allowed me to keep the documentation of the poetry-exec-plugin minimal.

[jnussbaum]

Here I use Semantic Line Breaks (https://sembr.org/) for the first time. It sounds convincing, but I'm curious to hear your feedback.

One of the big advantages, which is not even described in the specification: we will get cleaner git diffs, because changing a single word in the middle of a paragraph won't force us any more to change all line breaks of that paragraph.