Proposal: Breaking Change Check and a Deprecation Policy for alcops.json

[someC0d3r]

With remote configuration support introduced in #500 (feat: support remote ALCops configuration), compatibility between configuration files and analyzer versions becomes increasingly important.

The documented all-or-nothing fallback means that if an Extends configuration cannot be fully resolved, ALCops falls back to its built-in defaults, including ignoring local overrides. The diagnostic introduced through #328 makes this visible.

This raises a question about future changes to configuration options: How should removed, renamed or redesigned settings be handled without unexpectedly invalidating existing configurations?

For centrally maintained configurations, this could affect many projects at once - particularly when those projects use different ALCops versions.

Would it make sense to introduce:

• Automated compatibility checks that flag potentially breaking changes to configuration options, such as removals, renames, or changes to accepted values and types?
• A defined deprecation process, where obsolete settings remain supported for a documented transition period, with guidance on their replacements?
• Migration guidance and release notes explaining when compatibility will be removed and how consumers should update their configurations?

Similar to the obsoletion process in Business Central AL, a predictable transition would help teams keep shared configurations compatible while gradually updating their projects.

Is there already an established policy for this in ALCops or would it be worth defining one?