Linter: Support per-rule custom configuration options

[markokajzer]

part of #1204

Adds support for per-rule configuration

Approach

• Shared rule configuration such as enabled, severity, and file filters continue to be validated by the config schema.
• Custom options and their schemas are defined by the rules that own them.
• The linter validates custom options after all built-in and project-local rules are available.
• Unknown options and invalid values produce a configuration error before linting begins, including for disabled rules.

Error Handling

Validation stops at the first error. Unknown option names are grouped into a single error, while invalid values are reported one at a time.

For comparison, Rubocop 1.84 behaves as follows:

• Two unsupported option names: prints both warnings and continues.
• Two invalid values/types: stops at the first fatal error; the second appears after fixing the first.

Adjusted rules

html-allowed-script-type

Follow up on #1201 to add the configuration options missing from the initial implementation

• allowedTypes allows changing the list of permitted script types
• allowBlank controls whether the type attribute may be omitted

erb-no-unused-expressions

• allowedMethods allows adding receiverless methods that may be intentionally ignored

Configuration Example

linter:
  rules:
    html-allowed-script-type:
      enabled: true
      allowedTypes:
        - application/json
      allowBlank: false

    erb-no-unused-expressions:
      enabled: false
      allowedMethods:
        - breadcrumb

Alternatives considered

• Config-owned schemas: validate every built-in rule directly in @herb-tools/config. This enables one-pass validation, but couples config to the linter and cannot naturally support project-local rules.
• Central rule registry: store every rule class and schema in a dedicated RuleLibrary/registry. This makes discovery and validation explicit, but introduces another abstraction and potentially global state.
  • Note: Rubocop uses a Cop::Registry module. allAvailableRules serves a smaller version of that role, without introducing a registry abstraction just yet
• Static schemas on rule classes: avoids instantiating rules during validation, but makes defaults and TypeScript generics more awkward.