followup of #17151 (comment)

* perf: Store indent descriptors in a plain array

* Fix return type JSDoc

Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>

---------

Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>

* fix: improve `getGraphemeCount`

* Fix

* Fix

* Use `Graphemer` only

Signed-off-by: Stefan Bischof <stbischof@bipolis.org>

…ss (#17139)

* fix: validate `ignorePatterns` constructor option in `FlatESLint` class

* disallow string value

* Update LintMessage type to reflect implementation

I made three changes to `LintMessage` and `SuppressedLintMessage`

1. Many places that create `LintMessage`s don't set `fatal`, so I made
   it optional. This would be a breaking change if we made types part of
   our exports, but in this case I believe it's updating JSDoc
   documentation to reflect reality.
2. Added an optional `messageId` property that's set by reports from rules.
3. Added an optional, nullable `nodeType` property.
    - Reports from rules set it to a value.
    - `applyDirectives()` explicitly sets it to `null` for unused
      disable directives.
    - `Linter`'s `createLintingProblem()` explicitly sets it to `null`.

* Add missing LintResult type import

* Use LintMessage type

All of these previously referenced a `Problem` type that does not have a
definition.

* Replace ReportInfo type with LintMessage type

`ReportInfo` was defined within `report-translator.js` to be very
similar to `LintMessage`. It had one extra property, `source`, which
wasn't ever set, so it would've been removed anyway. In
`Linter.runRules()`, the return value from `reportTranslator()` gets
pushed into a `lintingProblems` array and returned, and the return type
annotation is `LintMessage[]`, which gives me confidence that
`ReportInfo` was intended to be the same type as `LintMessage`
elsewhere.

* Make ruleId required but nullable

Originally, we talked about the reverse - making `ruleId` optional but
non-nullable and relying on `report-translator.js`'s `createProblem()`
to normalize it. However, the `LintMessage` type would differ from
`createProblem()`'s return value only by `null` vs `undefined` for
`ruleId`. So instead, I made `ruleId` required but nullable and
explicitly set it to `null` in the few remaining places that didn't
already.

* Add missing null nodeTypes

`LintMessage.nodeType` is currently defined as required but nullable.
Actual implementations explicitly set it to `null` in a couple places
and omit it in several.

After discussion in #16968, we initially leaned toward making it
non-nullable but optional. I pursued that, but it resulted in slightly
more runtime code changes, including some branching in
`report-translator` to set it conditionally.

Instead, I'm presenting the opposite solution of updating the remaining
implementations to match the existing type definition by explicitly
setting `nodeType` to `null`.

* Update LintMessage docs

This updates existing documented properties to match the updated `LintMessage`
type and implementations.

`messageId`, `nodeType`, and `suppressions` remain undocumented.

…fig (#17184)

* feat: change default ignore pattern to `**/node_modules/` in flat config

Fixes #17113

* update warning message

…17194)