Restructure configuration mechanism

[hkupty]

This is a new take on the configuration mechanism. This is PR also changes the required JDK version to 21, effectively bumping Penna out of the 0.7.x branch.

It proposes a few fundamental changes:

• The configuration manager is now part of the API and irreplaceable;
  • Extensions can be added to the configuration manager for updating the configuration;
• Configuration updates can be either full or partial updates, but only on the level of the manager;
  • The storage will always treat the updates as full replaces;

Tasks needed on this PR before merging:

• [x] File watcher;
• [x] Alternative file (penna-test.yaml);
• [x] SnakeYAML implementation;
• [x] Replace old way and clean-up;

Desirable/Maybe in a follow-up PR:

• [x] More tests;
  • [ ] Property based tests for yaml?
• [ ] Audit config (last updated by provider) on storage level;
  • Providers are expected to be named anyways;
• [x] Atomic binding between provider and manager:
  • i.e. with this implementation, if the provider fails mid-way, it partially updates the configs in the storage;
• [ ] Initialization time log sink:
  • So providers and the manager itself can log errors, warning or debug during init;
  • It could be as simple as a queue that unloads after initialization is complete;
• [x] Meta-configuration:
  • Filtering providers during initialization;
• [ ] Better control over the manager lifecycle:
  • Currently the initialize method is public;
  • Ensure tests are also possible;
  • Ensure runtime can't tinker with this instance;
  • Ensure runtime can still reference it for direct update (if wanted);

[hkupty]

Not necessarily "atomic binding", but by making a two-step process we can first verify the configuration provider (and perform some meta-configuration, i.e. the file watcher option in yaml) before returning to the manager that it should be initialized, so we only initialize those that are correctly instantiated.

[hkupty]

On the meta-configuration level: It is not the manager's responsibility to figure out which provider should be added. It's the provider's own responsibility. For example, if no yaml configuraiton file exists, the provider will report false back to the manager and should not be initialized.

[hkupty]

Any further cleanups should happen in a subsequent PR as this one scope creeped a bit and is gigantic already.