Qlib’s region system parameterized

🌟 Feature Description

Make qlib’s region system fully parameterized so users can register and switch to non-us/cn markets (e.g., Nordics) without modifying core code. Region metadata (calendars, instruments, feature folders, filters) should be resolved dynamically from config/initialization parameters.

Motivation

Application scenario: Running qlib on Swedish equities via a custom qlib_ext_se package—today we must patch qlib internals because many components assume only us or cn.
Related works: qlib’s qlib_ext examples show how to add data packs, but they still depend on region-specific switches inside qlib.
Other info: We have local data under /data/xsto with its own calendars/instruments. We can initialize qlib_ext_se, but key subsystems (e.g., config.C["region"], filters, default provider URIs) only recognize the built-in regions, so we end up hacking global constants.

Alternatives

Maintain a fork that overrides region-specific modules, but this diverges from upstream and complicates upgrades. Another approach is to masquerade as us or cn, but that pollutes calendars/instrument sets and defeats the purpose of regional metadata.

Additional Notes

A more flexible region system could expose hooks or registration APIs for external packages: declare region name, calendar file paths, instrument configs, and default providers. That would let communities publish regional data packs that “just work” with qlib.init(region="se", provider_uri=...).

Start by tracing qlib.init, config.C["region"], the region-specific filters, and default provider URI handling, then compare them with the qlib_ext examples. Use the /data/xsto calendars and instruments as the external-region case. Done means a registered region can supply its metadata and work through initialization without changing qlib core constants.