feature: Support granular change codes and configuration via analysis_options.yaml

[flxapps]

Right now, our change detection is a bit "all or nothing." We categorize changes using a hardcoded ApiChangeOperation enum (e.g., featureRemoved, typeChanged), which leads to generic breaking change warnings that users can't easily customize or silence.

We should move to a more structured system where every detected change has a unique, granular code (like linting rules). This would allow us to categorize changes more precisely and give users control via their existing analysis_options.yaml.

Proposed changes:

1. Granular Change Codes:
Instead of generic operations, we should define specific codes for every scenario.

For example:

• CI01: Interface removed
• CP01: Parameter renamed
• CF05: Field static status changed
• This makes the changelog and debugging much clearer.

2. Configuration Support:
We can read a custom section in analysis_options.yaml (e.g., api_guard:) to let users override the severity of specific rules or ignore them entirely.

Example configuration:

api_guard:
  rules:
    # Ignore rename detection
    CP01: ignore
    # Treat adding optional parameters as "internal" instead of "minor"
    CP02: patch

Benefits:

• Allows teams to enforce strict semantic versioning where they want, but relax it for "experimental" features.
• Aligns with standard Dart tooling practices (lints).
• Makes the system extensible for future checks without hardcoding severity logic everywhere.