Automate linting version updates

[mikealfare]

Short description

We should automate linting dependency updates to reduce maintenance efforts. We moved all of these dependencies into .pre-commit-config.yaml, so the scripting should be pretty straight forward.

Context

You can update all of the dependencies at once in .pre-commit-config.yaml by running:

pre-commit autoupdate

Hence this workflow should look something like:

1. Checkout the repo
2. Create a new branch
3. pre-commit autoupdate
4. pre-commit run --all-files
5. Merge into main on GitHub if successful
6. Push new branch back up to GitHub and create a PR if not successful

Acceptance criteria

Preview Give feedback

1. If a new version of a linting dependency is compatible with our code, we should update to it automatically
2. If a new version of a linting dependency is not compatible with our code, we should get an open PR with the update so that we can resolve the linting errors
3. All linting dependencies should continue to be managed via .pre-commit-config.yaml
4. We can add a new check to .pre-commit-config.yaml without needing to update process
5. This process should not generate more than one PR, i.e. if it already detected an incompatibility, it should be skipped until this incompatibility is resolved
6. If it is impractical to enforce the PR approach, this process should instead create an alert in #dev-adapter-alerts
7. This is implemented for all first party adapter repos as well as dbt-adapters
8. We should consider placing any reusable components in dbt-labs/actions for other teams to use (e.g. Core)

Testing

Preview Give feedback

1. We could issue a PR to downgrade one of the linting dependencies and monitor for the update
2. Since the check for compatibility gets run before every commit, it would be difficult to test the incompatibility logic flow; if required, we would need to find a lint check that did not exist in an old version, but does exist now, and back out that change so as to trigger it on the version update

Security

There are no security concerns.

Docs

There are no end-user docs associate with this change. We could add a brief mention of this process in something like CONTRIBUTING.md.

Consequences

This will only impact development in the repos in which this is enabled, meaning this should not impact anyone.