Bump apis-common version 3.0.0 → 3.4.1 to match apis-bom

[PRAteek-singHWY]

Why

apis-common/pom.xml imports the project BOM as:

<dependency>
  <groupId>jp.co.sony.csl.dcoes.apis</groupId>
  <artifactId>apis-bom</artifactId>
  <version>${project.version}</version>
  <type>pom</type>
  <scope>import</scope>
</dependency>

${project.version} resolves to whatever this module's own <version> says - currently 3.0.0. The sibling hyphae/apis-bom is on 3.4.1, and apis-bom:pom:3.0.0 is no longer published to Maven Central, so the BOM import is unresolvable from a clean clone.

This surfaces in CI as:

ERROR Non-resolvable import POM: Could not find artifact
      jp.co.sony.csl.dcoes.apis:apis-bom:pom:3.0.0 in central
      @ apis-common/pom.xml line 17, column 19
ERROR 'dependencies.dependency.version' for junit:junit:jar is missing.
      @ apis-common/pom.xml line 51, column 17

(See hyphae/APIS#101 - the failing run that prompted this.)

The second error is a side-effect: apis-bom 3.4.1 pins junit at 4.13.2 in its <dependencyManagement>, so once the BOM resolves, the version-less junit dependency in this pom inherits its version correctly.

Change

One line in pom.xml:

-  <version>3.0.0</version>
+  <version>3.4.1</version>

Nothing else touched - no new dependencies, no behavior change, no rename, no build-script edits.

Verification

• apis-bom 3.4.1 installs cleanly (mvn install from a fresh clone of hyphae/apis-bom).
• After this change, mvn install in apis-common resolves the BOM, picks up junit 4.13.2 transitively, and builds.
• Confirmed end-to-end by running make build-apis-bom build-apis-common from hyphae/APIS.

Follow-ups (out of scope for this PR)

The downstream modules (apis-main, apis-ccc, apis-log, apis-web) likely have the same 3.0.0 → 3.4.1 drift and will need parallel bumps before the umbrella make build is fully green again. Happy to open those as separate PRs.

[FlawzyByte]

Hello @PRAteek-singHWY, thank you for your contribution as it's already mentioned in this PR:
#20
As i'm investigating further into possible de-centralizing (decoupling) from the other repo.