feat: add experimental build-tag support

[vytautas-astrauskas-sensmetry]

Depends on #346

An experimental feature that enables appending build tag (dev.<TAG> pre-release suffix) to a KPAR's version at build time without modifying the source .project.json on disk.

• 1.2.3 → 1.2.3-dev.42
• In workspace builds, versionConstraint fields that exactly pin a sibling
  project's base version are also updated (e.g. =1.2.3 → =1.2.3-dev.42).

The tag is exposed through the Java SDK and Maven plugin only (no CLI flag in this PR; will consider adding it in a later PR after confirming that the design implemented in this PR works.).

Java API

// New overloads — marked @Experimental in Javadoc
Sysand.buildProject(outputPath, projectPath, compression, buildTag);
Sysand.buildWorkspace(outputPath, workspacePath, compression, buildTag);

Maven plugin

<configuration>
  <buildTag>42</buildTag>
</configuration>

Or via property (useful in CI):

mvn package -Dsysand.buildTag=$BUILD_TAG

Empty-string is normalised to null, so an unset $BUILD_TAG is a no-op.

A typical CI pattern using a pom.xml default:

<properties>
  <sysand.buildTag></sysand.buildTag>   <!-- default: no tag -->
</properties>

mvn package -Dsysand.buildTag=$BUILD_TAG   # tag applied only when BUILD_TAG is set

[consideRatio]

The wish is to get incremental build versions for development builds of some kind - right?

The simplest option i think would be to not have any dedicated feature, but just use sysand as a CLI/binding to set the version without built-in logic.

Since any review effort to sysand is a work effort, is this functionality worth working towards now? I push back like this because there are significant ambitions worked towards already in a timeframe we struggle to deliver reliably against.

[vytautas-astrauskas-sensmetry]

The wish is to get incremental build versions for development builds of some kind - right?

The standard library is going to be released every month. Updating the version each month by hand is too painful and too risky. This approach is the easiest way I found for distinguishing these monthly releases.

The simplest option i think would be to not have any dedicated feature, but just use sysand as a CLI/binding to set the version without built-in logic.

This simplest option is, unfortunately, not so simple because it depends on support of file usages and correct conversion to IRI usages, which is #281. For this reason, I went with an explicit build tag flag, which is simpler and (hopefully) easier to review.

[vytautas-astrauskas-sensmetry]

Proper implementation is blocked by #281. Freezing this PR until it is completed.