chore: Reduce duplicities in configuration

[ctasada]

With the recent changes in #267 now is possible to reduce duplication of values.

Now the version is reduced to a single build.gradle configuration. Same for other module configurations that are also unified.

While testing I also found some unneeded variables in dependencies.gradle and some unusedDeclaredArtifacts which are also fixed.

Each change is in its own commit to allow for easier review.

[netlify]

✅ Deploy Preview for springwolf-ui canceled.

Name	Link
🔨 Latest commit	b06abd9
🔍 Latest deploy log	https://app.netlify.com/sites/springwolf-ui/deploys/64ba8ea588f52d0008041e0a

[timonback]

Hi @ctasada,
I like the change to reduce the amount of version string sprinkled around in this repo.

I like to keep the information whether it is a snapshot separate from SPRINGWOLF_VERSION, because I can be sure in the pipeline that builds on master will never build release version.

What I am currently unsure about is how to handle bugfix releases.
Assuming we release 0.13.0 and incremented to the next version 0.14.0. Now, we discover something requiring a bugfix aka small release 0.13.1. What to do?
Fix it in 0.14.0, cherry-pick backport it to a new branch created from the 0.13.0 tag (with increasing the version to 0.13.1 on the newly created branch first)?

[ctasada]

@timonback Regarding the bug fixing after releases I think the best approach is to link the release with a tag.

I see 2 ways of accomplishing it:
1.- Modify the Github workflow in a way that once the release is generated, it also creates a git tag This will allow to checkout and build a new tag with any needed bugfix in the future
2.- Modify the Github workflow so the release process is directly related to the tag creation. So once a new tag is created, the libraries release is executed and the version is updated.

Both approaches accomplish the same outcome, but are implemented in slightly different ways. I see that Github has different workflows in the marketplace that accomplish this. I have used both approaches with Gitlab for years and they work fine. The decision is mainly driven by minor tradeoffs and deployment preferences.