Use class literals instead of getClass() for resource loading (CodeQL java/unsafe-get-resource)

[vharseko]

Summary

Resolves all 27 CodeQL java/unsafe-get-resource alerts by replacing the
getClass().getResource(...) / getClass().getResourceAsStream(...) idiom with
an explicit class literal (<EnclosingClass>.class.getResource(...)).

getClass() returns the runtime class, so if a class is extended by a subclass
in another package — or loaded by a different class loader — the resource path is
resolved from a different location than the author intended. Pinning resolution to
the class where the code is written (a class literal) is the CodeQL-recommended
fix.

Why this is behaviour-preserving here

• Most call sites use absolute resource paths (/foo), which resolve from the
  class-path root regardless of package, so the runtime class never mattered.
• The only type that is actually subclassed, XmlTransformer, loads XSL via a
  constructor argument; all of its subclasses live in the same package and
  pass absolute paths (/xslt/...), so XmlTransformer.class resolves
  identically.
• Every site runs within a single class loader (application / plugin jar).

Scope — 27 sites across 18 files

Module	Files	Sites
commons/util/util	XMLHandler	1
commons/audit/core	EventTopicsMetaDataBuilder	1
commons/audit/servlet	AuditHttpApplication	1
commons/selfservice/example	ExampleSelfServiceApplication	1
cassandra-embedded	EmbeddedServer	4
commons/doc-maven-plugin	AbstractDocbkxMojo, AsciidocToPdfMojo, AsciidocPreProcessMojo, XmlTransformer, SyntaxHighlighterCopier, BootstrapCopier, Redirect, Robots, Htaccess, IndexHtml, WebhelpPost, Html, Bootstrap	19

Testing

All six affected modules compile.