Introduce JCasC configuration history tracking via listener extension point

[somiljain2006]

Fixes #955

Introduce support for tracking and viewing JCasC configuration history directly from the Jenkins UI. This change adds a CasCReloadListener extension point that is triggered after a successful JCasC application, allowing external components to react to configuration changes. A pluggable JCasCHistoryBackend abstraction is introduced, with a LocalFileHistoryBackend Implementation that stores configuration snapshots under the Jenkins home directory.

• Stores jenkins.yaml snapshots along with metadata (history.xml)
• Captures the user responsible for the change (or SYSTEM during startup)
• Implements a snapshot-based history model
• Enforces a retention policy (default: 50 entries)
• Handles timestamp collisions via suffix fallback
• Provides a ManagementLink UI to browse history and view snapshots
• Includes test coverage for storage, retention, concurrency, and ordering

Your checklist for this pull request

🚨 Please review the guidelines for contributing to this repository.

• Make sure you are requesting to pull a topic/feature/bugfix branch (right side) and not your master branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or in Jenkins JIRA
• Link to relevant pull requests, esp. upstream and downstream changes
• Did you provide a test case? That demonstrates a feature that works or fixes the issue.

[timja]

Most people use SCM for this, I don't think there's much point retaining this especially not shipping it built-in

for feature requests better to look at the most recently updated ones.

a bunch of the old feature requests were good ideas when the plugin was created but if there's no need for them now its just more code to maintain in the future better to limit our surface to what problems are actually facing