Centralize sensitive-config obfuscation pattern into a shared utility

Problem

The key-name obfuscation rules for sensitive config (passw|pass|passwd|secret|key|token + the OBFUSCATE_SYSTEM_ENVIRONMENTAL_VARIABLES override) are defined as statics on JVMInfoResource, a JAX-RS resource. Other layers reach into it:

• SystemTableImpl.set() calls JVMInfoResource.obfuscateIfNeeded() for security logging — business layer depending on a REST class
• ConfigurationResource.isOnBlackList() reads JVMInfoResource.obfuscatePattern directly

As more surfaces need the same masking (e.g. the config-overrides fix in #36919), the pattern needs one authoritative home.

Fix

• New com.dotcms.util.ObfuscationUtil owning the default pattern, the config-driven custom pattern, shouldObfuscate(), matchesCustomPattern(), obfuscateIfNeeded() and obfuscate()
• JVMInfoResource keeps its public members as thin @Deprecated delegates (they are public static and may be referenced by plugins)
• SystemTableImpl and ConfigurationResource switch to the utility

No behavior change — same patterns, same masking format.

Related: #36919 (config overrides not obfuscated).

Start by reading the obfuscation statics in JVMInfoResource, then trace their callers in SystemTableImpl.set() and ConfigurationResource.isOnBlackList(). Introduce the shared utility described in the issue and update those callers while preserving JVMInfoResource's public deprecated delegates. Done means the existing patterns, override behavior, and masking format remain unchanged.