Load mirth.properties.d drop-in configuration overrides on startup

[pacmano1]

Closes #50.

Files named *.properties under conf/mirth.properties.d are loaded on top of mirth.properties at startup, in lexical filename order, later files winning. The server never writes to the directory, so local configuration survives upgrades without hand-merging. This mirrors the existing vmoptions convention (base_includes.vmoptions -> custom.vmoptions).

All six mirth.properties readers apply the overlay: the launcher, the main server, the configuration controller, the WebStart servlet, extension statuses, and the Rhino optimization-level lookup in JavaScriptScopeUtil. The configuration controller keeps a separate file-backed config for version migration and password re-encryption, so those writes never bake drop-in values into mirth.properties.

Scope notes:

• Properties the server encrypts and writes back (database.password, keystore passwords) should stay in mirth.properties; a plaintext override in a drop-in keeps taking precedence and is never encrypted. Documented in the shipped mirth.properties.example.
• migrateKeystore() still reads mirth.properties directly; it's a one-shot legacy migration (pre-2.2) and was left alone.
• Layering the log4j2 configuration is split out to Investigate layered/drop-in configuration for log4j2.properties #404.
• Renaming the shipped defaults file away from mirth.properties (also floated in [IDEA] Allow multiple MC configuration files t be read on startup #50) belongs to the existing branding effort (Alter the build pipeline so that build artifacts are branded as "openintegrationengine" or "oie" instead of "mirth" #165, Standardize artifact naming to align with project branding #220) rather than this PR.

To verify: create conf/mirth.properties.d/10-test.properties containing http.port = 8199, start the server via oieserver, confirm the startup log reports the web server on port 8199 and that conf/mirth.properties is unchanged afterward.

[github-actions]

Test Results

682 tests   682 ✅  2m 11s ⏱️
115 suites    0 💤
115 files      0 ❌

Results for commit 3f9eea1.

♻️ This comment has been updated with latest results.

[pacmano1]

Design notes, so the reasoning doesn't live only in my head:

• A drop-in directory over a special sibling file (custom.properties, local.properties): matches the conf.d/sysctl.d convention, scales past one file, and the name derives from the parent file. The vmoptions chain (base_includes -> custom.vmoptions) is the in-repo precedent for layered config.
• The sample ships as mirth.properties.example so the loader ignores it; copy it to a *.properties name to activate.
• The server does not modify mirth.properties in normal operation (verified across a boot: identical content). First boot only trims trailing whitespace on empty values, appends ;upgrade=true to the Derby URL, and generates keystore passwords. So the directory exists for upgrade hygiene: the installer preserves mirth.properties, and tar.gz upgrades can replace it wholesale without hand-merging.
• Keystore gotcha, verified live on a fresh install: keystore.storepass/keystore.keypass auto-generate only when BOTH are still the shipped default. A drop-in overriding just one suppresses generation and the other stays at its published default. Pre-existing guard; the sample file documents it.
• Drop-ins are parsed with java.util.Properties in every reader so the launcher-side and server-side worlds see identical semantics. ${...} references would interpolate only on the server side, so the sample avoids suggesting them.
• log4j2 layering split to Investigate layered/drop-in configuration for log4j2.properties #404. Renaming the shipped defaults file (also floated in [IDEA] Allow multiple MC configuration files t be read on startup #50) belongs to the branding effort (Alter the build pipeline so that build artifacts are branded as "openintegrationengine" or "oie" instead of "mirth" #165/Standardize artifact naming to align with project branding #220).