feat: add `validate` subcommand to check configuration files

[outofcoffee]

Feature Request

Add a validate subcommand to the Imposter CLI that parses and type-checks a configuration file without starting the mock server. This would let users catch errors during development/CI before deploying.

User Story

As a user managing multiple Imposter configurations across environments, I want to run imposter validate ./config/imposter.yaml in my CI pipeline or pre-commit hook, so I can catch configuration errors early instead of discovering them at runtime.

Proposed Behaviour

# Basic usage
$ imposter validate ./config.yaml
Configuration file is valid.

# With errors
$ imposter validate ./config.yaml
Found 3 errors:
  - Line 12, column 5: unknown field 'statikData' (did you mean 'staticData'?)
  - Line 24: resource '/users' references file './responses/users.json' which does not exist
  - Line 31: invalid regular expression '[invalid' in path pattern

# JSON output for programmatic use
$ imposter validate ./config.yaml --json
{"valid": false, "errors": [...], "warnings": [...]}

# Validate all configs in a directory
$ imposter validate ./configs/

What to Validate

The subcommand should check:

1. YAML/JSON syntax — malformed files cannot be parsed
2. Schema conformance — unknown fields, missing required fields, type mismatches
3. File references — paths in staticFile/file/scriptFile fields point to existing files
4. Resource conflicts — duplicate paths, overlapping route patterns
5. Script compilation — referenced JavaScript/Groovy files have basic syntax validity (optional, could be a warning)
6. Store configuration — store backend references that are configured but never used (or used but never configured)
7. Plugin detection — referenced plugins are available/installed

Implementation Considerations

• This could potentially reuse the existing config parsing/loading code path that imposter-go already has, just without starting the HTTP server
• Exit code should be non-zero on validation failure (for CI usage)
• The --json flag enables machine-readable output for tooling integration
• Directory scanning should respect the same config discovery logic as the up/start command (including recursive mode if IMPOSTER_CONFIG_SCAN_RECURSIVE is enabled)
• Consider supporting a --warnings-as-errors flag for strict CI validation
• Performance matters less than thoroughness here — users will accept a few hundred ms to get thorough checks