SOLR-18057: Prefer Path.resolve over Path.of for derived paths

[openworld-maker]

This PR addresses SOLR-18057 by eliminating unnecessary Path→String→Path conversions and using Path.resolve(...) when the base is already a Path (starting with BinaryFieldTest noted in the issue).

No intended behavior change; refactor only.

What changed

• Refactored TestBinaryField to use TEST_HOME().resolve("collection1").resolve("conf") and resolve(...) for file paths.
• Applied the same cleanup pattern in related tests where path bases were already Path:
  • TestRawTransformer
  • TestCustomCoreProperties
  • TestCoreDiscovery
  • TestLazyCores
  • CoreAdminCreateDiscoverTest
  • CoreAdminHandlerTest
  • ReplicationTestHelper
  • TestSystemIdResolver

Validation

• Focused tests passed:
  • :solr:core:test --tests org.apache.solr.schema.TestBinaryField
  • :solr:core:test --tests org.apache.solr.util.TestSystemIdResolver
  • :solr:core:test --tests org.apache.solr.response.TestRawTransformer
  • :solr:core:test --tests org.apache.solr.TestCustomCoreProperties
• ./gradlew check was attempted and hit unrelated environment/flaky issues (CloudSolrClientCacheTest flake and RAT task wiring check in this local environment).

[epugh]

This looks reasonable. Would it be possible to use our various validation tools to prevent this from happening in the future?

[dsmiley]

Tooling: There's nothing to ban. I wish there was a PR/review mechanism that would basically point out usages of Path.of that are new/added for scrutiny. Notice that the JIRA issue includes a comment by me with a GitHub "CodeQL" query. I'm not yet sure if there's a mechanism GitHub offers to support this use-case.

[epugh]

I was thinking that one of ecj or error prone or forbidden APIs checkers would keep this from coming back.

[epugh]

I dug around a bit and the only way to enforce this would be to write a custom BugChecker in Error Prone which probably isn't worth it.

[epugh]

I ran the tests and they all passed local...

[epugh]

tests pass..