Add support for exempting i18n/translation commits from Redmine validation

[ogajduse]

Problem

Currently, all commits in repositories with redmine_required: true must follow the format fixes #1234 - description or refs #1234 - description to pass validation. However, translation/internationalization commits often don't have specific Redmine issues associated with them, causing these legitimate commits to fail validation.

This issue originated from discussion in theforeman/theforeman-rel-eng#519 (comment) where we need to handle locale/translation updates that may not have specific Redmine issues but still need to pass validation.

Proposed Solution

Add support for exempt_patterns configuration that allows certain commit message patterns to bypass Redmine validation requirements while maintaining validation for regular commits.

Features:

• Global default patterns applied to all repositories (for common i18n patterns)
• Repository-specific override capability for special cases
• Regex pattern matching for flexible commit message formats
• Backward compatible - no breaking changes to existing configuration

Example Configuration:

# Global patterns applied to ALL repositories (unless overridden)
global_config:
  exempt_patterns:
    - "^i18n - "
    - "^Localization - "
    - "^Update translations"
    - "^Automatic locale update"

# Repository uses global patterns automatically
theforeman/foreman:
  redmine: foreman
  redmine_required: true

# Repository can override with custom patterns
theforeman/special-repo:
  redmine: special
  redmine_required: true
  exempt_patterns:
    - "^Bot update - "
    - "^Automated sync - "

Example Exempt Commits:

• ✅ i18n - Update Japanese translations
• ✅ Localization - Fix German strings
• ✅ Update translations for 3.5 release
• ✅ Automatic locale update from Crowdin

Regular commits would still require Redmine references:

• ❌ Add new user management feature (needs fixes #1234 -)
• ✅ fixes #1234 - Add new user management feature

This solution addresses the core issue while preserving the validation requirements that ensure proper issue tracking for development work.

[ekohl]

FYI: I don't think we need an issue for every PR we open.

[ogajduse]

Understood, in most cases, it should be enough to provide the context in the PR description. Will keep that in mind.