Remove leading and trailing whitespaces from VERSION files for crate and maven assembly rules

[farost]

What is the goal of this PR?

We resolve issue #380 by trimming input version values from VERSION files for maven and crate artifacts assembly rules. It solves the problem of VERSION files being passed as version_file to the respective rules after being formatted to have an additional empty line in the end, which is a standard convention for files and a common IDE setting, or just being formatted incorrectly while containing a valid value.

From now on, VERSION files passed into assemble_maven and assemble_crate can have any leading and trailing whitespaces.

What are the changes implemented in this PR?

We add trim() calls for all the .kt scripts reading version files. This behavior used to exist for many .py scripts (with strip() for Python string), but these places were left forgotten (and not noticed by us as we use --define version=$(cat VERSION) in most of our assembly pipelines). We also add a respective check for trimmed version values into the maven deployment script to prevent users from forgetting to format their input versions while using any pom file as it can lead to corrupted snapshots, snapshot repositories URLs, and other automation failures.

[vaticle-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [x] This change is trivial and does not require a code or architecture review.

Code

• [ ] Packages, classes, and methods have a single domain of responsibility.
• [ ] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [ ] The code is canonical and the minimum required to achieve the goal.
• [ ] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [ ] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [ ] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [ ] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [ ] Any required build and release automations are updated and/or implemented.
• [ ] Any new components follows a consistent style with respect to the pre-existing codebase.
• [ ] The architecture intuitively reflects the application domain, and is easy to understand.
• [ ] The architecture has a well-defined hierarchy of encapsulated components.
• [ ] The architecture is extensible and scalable.