Figure out how we want to handle the git / release workflow going forth

[JulianKarhof]

I don't think the rules we currently have for commits, PR's, etc. are ideal for the continuing development of this repository. Therefore I'm proposing a couple changes to hopefully make stuff less confusing and easier to automate.

No squash merging going forth

This one just makes sense if you think about trying to go back and undo a commit within a branch after it has been squashed.

Only conventional commits within branches

This is the logical consequence of the before change. If we merge all branches normally, let's keep the history clean by using conventional commits. (There are ways of enforcing this if needed)

PR and tag based change-logs

To prevent every commit from showing up on the change-log, and to give more freedom when deciding on a PR title as well as give proper credit to the person who contributed, let's use https://github.com/lerna/lerna-changelog for change-log generation going forth.

This one I am the least sure about, but it'd probably be worth a try, considering it would help with attributing contributions to whoever worked on the PR instead of who merged it. We can continue using lerna to version bump package versions and release, but when switching to this we would stop having lerna generate CHANGELOG.md's and solely use GitHub as a change-log source.

Add an action that automatically releases for us

This would include pushing a new commit along with a tag, generating a change-log and creating a release on GitHub. This is more of a consequence of the new workflows, since this would help release even without having the repository cloned locally and the correct setup.