🚀 Feature: Add an on-by-default "Config" plugin

[JoshuaKGoldberg]

Feature Request Checklist

• I am using the latest published version of all Flint packages.
• I have searched for related issues and found none that matched my issue.

Overview

Splitting out of #2152:

I personally prefer the idea of the Knip-style config hint 😁 Not sure how annoying it could make composing configs though. If it were up to me, I'd do it and revert later if it's too annoying.

Originally posted by @barrymichaeldoyle in #2086 (comment)

Flint right now doesn't have a real way to lint just the Flint config (flint.config.*) file. But there are quite a few things we would want to lint for users:

• 🚀 Feature: config hints for redundant configurations #2152
• Merging multiple .rules({ ... }) into one
• Detecting duplicate entries ([ts.presets.logical, other, ts.presets.logical])
• Maybe even sorting entries in some stylisticStrict equivalent

Quoting #2152 (comment):

Yeah. This isn't the first time -and I don't think will be even close to the last- where we've discussed having some kind of linting for the Flint config. Which is tricky as a whole because (thinking out loud):

1. We have a lot of points we'd want to enable, such as this one
2. Each of those points is effectively a lint rule: they have syntax to detect, a range to report, and fixes/suggestions
3. We basically want to have a dedicated Flint Config plugin...
4. ...but don't want to ask users to always configure that in their config file

Proposal: how about making a Flint config that's always-on, but can be configured?

defineConfig({
  configLintingPropertyNameTBD: {
    // configuring the rule like any other
    configurationRedundancy: { someOption: true },
    someOtherRuleToBeDisabled: false,
  },

  ignore: [ /* ... */ ],
  use: [ /* ... */ ],
});

...and this "redundant configuration" point can be one of those rules?

Additional Info

❤️‍🔥