refactor(config): share config path resolution and JSON loading via ConfigFile

[Rushaway]

Summary

• Config, AccessManager, SourcemodConfig and TriggerManager each repeated the same four lines of config_folder/config_filename/config_filepath resolution, and three of them repeated the same json.load(..., object_pairs_hook=OrderedDict) call.
• Extracted a ConfigFile base in Config.py that owns path resolution plus a load_json(ordered=...) helper, and made all four inherit from it.
• Logger names are unchanged: logging.getLogger(self.__class__.__name__) still resolves to the subclass.

Composition vs inheritance

The issue suggested "compose or subclass Config". Subclassing Config itself would have been wrong here — SourcemodConfig and TriggerManager already take a Config instance and store it as self.config, so inheriting Config would have made self.config mean two different things in the same object. Hence a separate ConfigFile base holding only the file concern.

Error handling deliberately left alone

The issue also noted the inconsistent error handling. I did not unify it here: Config/SourcemodConfig still catch ValueError and return 1, AccessManager/TriggerManager still propagate. Picking one is a behavior decision affecting server operators, so it's split out into #164 rather than smuggled into a dedup refactor.

Closes #153

Test plan

• All four classes load their real config files from config/ with identical results: 16 config keys, 1 admin, 21 SM flags, 11 voice triggers.
• Logger names verified unchanged (Config, AccessManager, SourcemodConfig, TriggerManager).
• OrderedDict behavior preserved where it applied.
• Fed all four a malformed JSON file and confirmed per-class error semantics are byte-identical to before: Config → 1, SourcemodConfig → 1, AccessManager → raises, TriggerManager → raises.

🤖 Generated with Claude Code

[Rushaway]

Self-review: two judgment calls worth your eyes. (1) I did not subclass Config as the issue suggested -- two of these classes already hold a Config as self.config, so that would have collided; a separate ConfigFile base avoids it. (2) I kept the inconsistent error handling exactly as-is and split it to a follow-up issue, because making a config typo newly refuse to start the bot is an operator-facing behavior change, not a refactor. Verified equivalence against the real config files and against malformed input per class.

[Dolly132]

Tested, works fine as intended.