feat: Implement caching for FlatESLint

[nzakas]

Refs #13481

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[x] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

This PR implements caching for FlatESLint by making the following changes:

1. Enabling cache: true as an option for FlatESLint
2. Adding back all of the caching functionality that was removed for the first developer preview
3. Creating a toJSON() method on each config object that will normalize it into a form that is more appropriate for storing in the cache

Is there anything you'd like reviewers to focus on?

For now, I throw an error when trying to serialize a config object where either the parser or the processor are objects instead of strings because it's not clear how best to serialize these. I see the following possible paths forward from here:

1. We ask that parsers and processors publish a name property that we can use for caching purposes and otherwise throw an error. This seems like the simplest approach.
2. We disallow objects for processor (same as eslintrc) and parser (different from eslintrc -- problematic for back compat reasons)
3. We figure out some way to hash a value for objects. Maybe for parser we could hash to toString() of the parse() method, and maybe for processor we could hash the toString() of both preprocess() and postprocess()?

[netlify]

✅ Deploy Preview for docs-eslint canceled.

Name	Link
🔨 Latest commit	0b813ea
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/62f416d3b3d3f5000955fe56

[btmills]

LGTM!

For future serialization, I'm not a big fan of 2, and it sounds like you aren't either. As a variant of option 1, we could call it cacheKey and encourage packages to include version as package-name@1.2.3, making it even more thorough. As a fallback, option 3 seems like a reasonable best effort.