RANGER-5802: Fix maven-assembly-plugin warnings in distro build

[kumaab]

What changes were proposed in this pull request?

Every build logged 203 assembly-plugin warnings (1385 log lines) caused by stale entries in the assembly descriptors:

• 193 "patterns were never triggered": include/exclude patterns that match no artifact. Solr/ES audit destination jars left behind after RANGER-5632 removed those dependencies (solr-solrj, httpasyncclient, httpcore-nio, httpmime, jetty-client); leftovers of the Jersey 1 -> 2 and log4j migrations (hk2, javax.inject, osgi-resource-locator, commons-configuration 1.x, log4j, slf4j-log4j12, noggit); rules that can never match, such as a plugin jar listed in its own dependency filter and excludes with no matching include; and entries in a moduleSet that does not package them.

• 10 "filesystem-root relative reference, which is not cross platform compatible": outputDirectory paths starting with "/" in the elasticsearch plugin descriptor. Normalized in the solr, schema-registry and admin-web descriptors as well.

• A pattern was dropped only when it was unmatched for every module of its moduleSet. Packaging is unchanged: the file listings of all 30 tarballs are identical before and after, both single-threaded and with -T 8.

• Also fail the build-17 CI job when either warning appears, so stale descriptor entries are caught in review instead of accumulating. A silent symptom of the same warnings is a tarball that quietly loses jars.

How was this patch tested?

• Warnings gone. Same mvn -T 8 clean package on master vs this branch:
  193 "patterns were never triggered" and 10 "filesystem-root relative
  reference" warnings drop to 0, which is 1,385 fewer log lines (~63 KB) per build.

• Packaging unchanged. Compared this PR's target-17 CI artifact against the
  master run of d87bd9ee1 (the base commit; same Maven and JDK). same tarballs,
  no entry present on only one side — no jar added, dropped or
  renamed.

• Removals verified per module. These warnings are logged once per module, so
  an entry was removed only when unmatched for every module of its moduleSet.
  Descriptors that legitimately need those jars (e.g. Solr jars in ews/lib for
  admin and kms) are untouched.

• New CI check verified against a deliberate break. Simulated the usual cause
  by pinning commons-io to an older version in agents-installer/pom.xml while
  the descriptors still include ${commons.io.version}:

  • Maven still reported BUILD SUCCESS, with 24 warning blocks, and
    install/lib/commons-io-2.17.0.jar silently vanished from 13 plugin
    tarballs — installer scripts would fail at runtime.
  • The check exited 1 and listed each stale pattern next to the archive it
    broke, one line per pattern per archive rather than Maven's per-module
    repeats.
  • Because the check runs before the upload steps, the broken target-17
    artifact is never published and the downstream docker jobs are skipped.

• It also correctly stays quiet on pom changes that break nothing: excluding
  joda-time from hdfs-agent produced no warning, since other modules in the
  same moduleSet still supply that jar and it still ships.