IGNITE-28894 C++: add nested thin-client modules to the dev-mode classpath

[anton-vinogradov]

CreateIgniteHomeClasspath() (used when IGNITE_NATIVE_TEST_CLASSPATH=true, i.e. C++ tests run against an exploded dev build) scans modules/ only one level deep: for every direct child it calls ClasspathExploded(child, false), so nested maven modules are never visited.

modules/thin-client is not a maven module itself (no pom.xml) — it is a grouping directory holding thin-client/api and thin-client/impl. Neither their target/classes nor their target/libs end up on the classpath of a node started from C++, and they cannot arrive any other way: copy-dependencies in parent/pom.xml sets <excludeGroupIds>${project.groupId}</excludeGroupIds>, so ignite artifacts are never copied into target/libs.

jdeps confirms real bytecode references from ignite-core into the thin client:

• org.apache.ignite.Ignition -> IgniteClient, ClientException, TcpIgniteClient
• management commands (DeactivateCommand, SetStateCommand, StateCommand, WarmUpStopCommand, CommandUtils) -> ClientCluster, IgniteClient

They are resolved lazily, so a node currently starts fine (verified with both the default config and the cache-test.xml used by the C++ core tests). But any path reaching Ignition.startClient() or a management command from the C++-hosted JVM fails with NoClassDefFoundError. The hole is latent — it is not yet observable in the existing C++ suite.

The same problem was already solved for modules/binary when it was split into api/impl: CreateIgniteHomeClasspath() carries an explicit recursive special case for that directory (ClasspathExploded(home + "/modules/binary", true)). Moving the thin client into nested modules did not add the matching line — the C++ side was not touched.

This change mirrors the binary special case for modules/thin-client in both linux/utils.cpp and win/utils.cpp.

The shell launch scripts already account for this: bin/include/build-classpath.sh and build-classpath.bat both pass modules/thin-client explicitly (right next to their modules/binary entry). So the move into nested modules was completed on the shell side and only the C++ classpath builder was left behind — this PR brings it in line.

A test is added in core-test (classpath_test.cpp) asserting that the compiled classes of all four nested modules — binary/{api,impl} and thin-client/{api,impl} — are present on the classpath returned by CreateIgniteHomeClasspath(). It fails on master (thin-client missing) and passes with this fix.

A generic two-level scan is deliberately avoided: it would additionally pull extdata/* (p2p / URI-deployment test data that is intentionally kept off the classpath), platforms/dotnet and web/*-test into the dev node classpath.

[anton-vinogradov]

TeamCity RunAll (branch pull/13373/head).

The new core-test check ClasspathTestSuite: TestNestedModulesOnDevClasspath passes on all three C++ suites (Linux, Linux Clang, Win x64 Release), confirming thin-client/{api,impl} are now on the exploded dev classpath.

The remaining RunAll failures are unrelated to this change — the diff only touches the C++ classpath builder, while the failures are in .NET, Java Cache/PDS/Snapshots/Queries/WAL and Messaging suites. Each reproduces on master and on unrelated PR branches, e.g.:

• IgniteWalRebalanceTest.testWithLocalWalChange — flaky, fails on master (IGNITE-28869);
• IgniteClusterSnapshotSelfTest.testClientHandlesSnapshotFailOnStartStage — flaky;
• CacheNearReaderUpdateTest.* — fails on master (12/12 recent runs);
• .NET IgniteConfigurationTest.TestMulticastIpFinder — flaky, fails on master.

The C++ suite FAILURE itself comes from igniteOdbcTest terminating abnormally due to a missing joou runtime dependency after the Calcite 1.42 bump, tracked and fixed separately in #13372 — not related to the classpath change here.