Address the serious design flaws in renovate configuration linting

Current implementation of the renovate config validator has some serious flaws that make it unsuitable to be used as a pre-commit hook

• hook has entire renovate tool as a dependency making its installation huge and also full of installation warnings due to use of deprecated or insecure packages
• hook version is updated too often and this causes cascade spamming of dependency update for hook users, especially as the config of renovate does not really change much, maybe few times a year, but the updates rate is ridiculous high, sometimes even more than one per day
• running the hook takes too much time, side effect of having a huge dependency tree

The fact that to validate the config we need the entire tool is the main issue, especially as most people do rely on an external hosted service to run renovate itself.

How can this be achieved?

• ensuring renovate esports a standard JSON schema for the config file and use only this to validate config. While a JSON schema might not catch everything, it would at least have a minimal footprint
• ensure renovate-config-validator is published separated on npmjs and that it does not have a dependency on renovate itself. Might not be an easy task.
• others?

The issue names the renovate-config-validator pre-commit hook and its npmjs packaging, but no repository files or tests. Start by examining how the hook invokes Renovate and how the validator is published; compare its dependency footprint and runtime with the proposed schema-based approach. Done requires an agreed design for standalone validation, versioning, and acceptable hook performance.