Scaffolding CLI / next steps

Nobody has claimed this yet.

Okay so I know this is a PoC right now, but I really like this idea and would be interested in taking it a step further :)

This would mean:
- Publishing a basic CLI so one can `npx create-esm-react-app` ⚙
- Making the default project "production-ready" (for evergreen browsers). That means dropping code-splitting with `import()` (or rather making it opt-in, see next point) because of browser support and providing some sensible ESM-compatible defaults for styling and routing, as mentioned in the README already. 🚀
- Since we don't run any tooling, the CLI could be really simple. Collect some options (`Use code splitting with import()? y/N`, `Use service worker for offline caching? y/N`, ...), then scaffold the project and done. 🏗
- Since we don't have a build step and are not transpiling with `Babel`, I'd suggest automatically creating a `.browserslistrc` based on the scaffolded project and adding an eslint config with [`eslint-plugin-compat`](https://www.npmjs.com/package/eslint-plugin-compat) so users get warnings if they use features not available in all major ESM-equipped browsers. ⚠
And if the config files are already too much "build tooling", we can at least recommend it in the docs :)
- And of course, docs. Covering both usage of this tool as well as what's generally required for a proper ESM setup, e.g. HTTP2 w/ Server Push highly recommended 📃

What do you think about this?

Start by reviewing the README and the current proof-of-concept structure to understand the existing scaffold. The proposal spans a publishable CLI, interactive options, browser and ESLint configuration, project defaults, and documentation, so a contributor would first need to split it into a defined scope and acceptance criteria.

Written by the indexing model from the issue text.