Add ZstdCompressAction to support configurable Zstandard compression levels

[katstack]

This PR adds ZstdCompressAction, replacing the generic CommonsCompressAction("zstd", ...) path (added in #1514) with a dedicated action that supports a configurable compressionLevel, following the same incremental pattern already used by GzCompressAction (LOG4J2-2598) and ZipCompressAction.

Supported range is the standard positive Zstd levels [1, ZstdConstants.ZSTD_CLEVEL_MAX] (currently [1, 22]). compressionLevel=-1 (unset) continues to resolve to the Zstd default level (3), consistent with the existing behavior documented in FileExtension/rolling-file.adoc.

What this PR deliberately does not do

Negative ("fast compression") Zstd levels are not supported. The rolling-appender framework uses Deflater.DEFAULT_COMPRESSION (-1) as a format-agnostic sentinel for "unspecified compression level," so an explicit compressionLevel=-1 would be indistinguishable from "not set." On main, compressionLevel has already been replaced by a more generic compressionOptions map (#2921); on 2.x it remains the mechanism, so this PR stays scoped to extending it rather than adding another special case on top of the sentinel.

Testing

ZstdCompressActionTest covers the new validation/mapping logic, including a test pinning the currently-assumed ZstdConstants bounds so a future zstd-jni/commons-compress upgrade that shifts them fails loudly instead of silently drifting from the documented range. Also ran the existing GzCompressActionTest/ZipCompressActionTest/Bzip2CompressActionTest/rolling-appender suites locally with no regressions, and ./mvnw verify passes on both JDK 8 and JDK 17.

References

• Configurable compression algorithms #2950 — ongoing discussion on generalizing compression configuration.