chore: Switch to pinned nanoversion strategy

[xli1996]

what

This PR adds pinnedNanoVersions property, so that project will try to pin each upstream version update in pom.xml instead of using version range which always selects the latest version.

e.g.
[7.3.0, 7.4.0) -> 7.3.0-99 after each build

why

• better reproducible builds, master/release branch won't follow latest upstream dependency because of version range. Local build dependencies can be traced more easily.
• branch become more stable since it will reject broken changes from upstream.
• version bump commit will be serperated from actual code change so that broken change can be targeted easily.

The current git workflow:

That is brought up by Ksql team initially because they want to have better reproducible builds. And with that change, version bumps will only happen when the upstream build is compatible. That means the mater branch will be more stable and reject broken upstream changes.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}