ci: disable dependabot non-security updates

[agilgur5]

Motivation

• similar to Workflows https://github.com/argoproj/argo-workflows/pull/12487, most of the automated updates from dependabot here cause problems, a lot of noise, and use up CI time, all without much benefit

  • most often are small patch updates of devDeps that don't affect our usage of them
  • and then subsequent PRs for each individual patch bump etc
  • the majority of PRs in this repo are these updates -- noise would be an understatement.
    • Stats: 288 out of 496 PRs are from dependabot. 164 of those were closed unmerged due to superseding PRs etc. Plus older PRs from Snyk (which also does non-security updates) and probably others I'm missing
  • some also cause a lot of breakage when they pass CI but break something in a way that doesn't have an automated test
  • for instance, major updates like https://github.com/argoproj/argo-ui/pull/227#issuecomment-1879870942, https://github.com/argoproj/argo-ui/pull/297#issuecomment-1747387417, https://github.com/argoproj/argo-ui/pull/387#issuecomment-1679493537, https://github.com/argoproj/argo-ui/pull/260#issuecomment-2235160404, etc, etc
  • given that this repo is not maintained much, no one is there to detect that or to ensure deps were properly updated
    • so instead this causes breakage that goes unnoticed or unmentioned for months, as with #469 etc
    • less frequent, manual updates are much, much safer than this as such
    • and since it isn't really maintained, leaving it in a consistent, working state is also much better than an unknown, potentially broken state
    • any dep updates should be intentional

• Note that this intentionally does not impact security updates. Security updates will still happen automatically

  • per the linked docs:

    This option has no impact on security updates, which have a separate, internal limit of ten open pull requests.

  • that is why I specifically used this configuration

Modifications

• set open-pull-requests-limit: 0 in dependabot.yml for all our currently specified package ecosystems

• also re-order the package ecosystems and add some comments equivalent to Workflows

  • could potentially split NPM prod and devDeps in these two as well, but I think this is fine for now

Verification

GH has no way to actually test this, but this same configuration has been used in Workflows for nearly a month now and is also something I previously implemented in other repos that I have maintained (example).

Future Work

Could potentially split NPM prod and devDeps with different settings as mentioned above

[agilgur5]

so instead this causes breakage that goes unnoticed or unmentioned for months

Correction, years, per #567