config files in readme should not encourage top level config. overrides only.

tl;dr: without adopting a new file format, we can get people ready by doing suggesting folks do:

```js
// .eslintrc.cjs
module.exports = {
root: true,
overrides: [
/* configs here */
]
}
```
(no top-level config, overrides-only), and that's all there is to it!

--------------------

Top level configs are problematic.
- https://eslint.org/blog/2022/08/new-config-system-part-1/
- https://eslint.org/blog/2022/08/new-config-system-part-2/
- https://eslint.org/blog/2022/08/new-config-system-part-3/
- https://eslint.org/blog/2023/09/preparing-custom-rules-eslint-v9/
- https://eslint.org/blog/2023/10/flat-config-rollout-plans/

We can start getting folks used to this style of config by forbidding top level configs and only using overrides in our documentation.
This will make the migration to eslint 9 (or the new config file, which is usable today) easier.

But the key take away is that config files will be overrides-only, dn the future.

Right now, folks can opt in to the eslint9 way entirely, but the ecosystem isn't ready. So only `overrides` in the classic config is a good stepping stone.

Here are some examples of this:
- https://github.com/embroider-build/addon-blueprint/issues/71#issuecomment-1341912431
- https://github.com/NullVoxPopuli/eslint-configs
- in this one, folks will say it looks complicated, but they haven't admitted to themselves yet that managing eslint configs _is_ complicated, and making it look simple is hard -- but also reasoing about what your config even is doing is hard (which, as a reminder, is one of the motivator for moving to a flat / overrides-only config)

both of these examples show how we can use the same set of configs for _every_ project -- and with easy escape hatches (overrides).