Improve AppPaths

[yurloc]

Hi @gitgabrio, I came across #5777 and noticed a few things that could be improved a little further (in my opinion). So I decided to take a stab at it while it's fresh. Let's see if you find this useful as well.

• The isJar flag was useless because it was true on every invocation of the method.
• I find it simpler to feed the transformation method with just a path than repeating the same lambda over and over.
• I noticed that Paths.get() is deprecated so I replaced it with Path.of().

How to replicate CI configuration locally?

Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.

build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

How to retest this PR or trigger a specific build:

• for pull request and downstream checks

  • Push a new commit to the PR. An empty commit would be enough.

• for a full downstream build

  • for github actions job: add the label run_fdb

• for Jenkins PR check only

  • If you are an ASF committer for KIE podling, login to Jenkins (https://ci-builds.apache.org/job/KIE/job/drools/), go to the specific PR job, and click on Build Now button.

[gitgabrio]

Thanks @yurloc , but I just modified this class and, for the moment being, I think it is better to keep it as it is.
Some side notes:

1. some of the refactoring (mostly, the static methods) are aimed at improve testability (this class has never been tested before), even if currently I had no time to extend them
2. Path.of and path.resolve have completely different semantics
3. I saw that the isJar boolean is always true, but for the moment being I preferred to kept it in the static method (see above about tests)

I spent enough time on that and, regardless of test/downstream results (that, we are discovering, are missing lot of corner cases), I would prefer (for the moment being) to avoid further modification on it: I hope it would make sense