* More helpful README

Updated to include more details about Next.js, link to the interactive tutorial, showcase, etc. Content mostly based on the official Next.js site.

* create-next-app readme

An updated readme with more details on options, benefits, etc.

* Apply edits from code review
Co-authored-by: NLuis Alvarez D. <luis@vercel.com>

* Remove redundant intro

* Update packages/create-next-app/README.md

* Remove introduction and list in showcase

* Apply suggestions from code review

* Update packages/next/README.md
Co-authored-by: NLuis Alvarez D. <luis@vercel.com>
Co-authored-by: Nkodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>

Fixes #15342

Co-authored-by: NJoe Haddad <joe.haddad@zeit.co>

Closes #15330

Co-authored-by: NJoe Haddad <joe.haddad@zeit.co>

Co-authored-by: NJoe Haddad <joe.haddad@zeit.co>

This particular variable was not being read correctly. Added a test for the behavior.

Fixes #15261

* Do not duplicate compilation errors

* Add tests

* Attempt to fix test

* Fix test

For reference: https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines

Fixes https://github.com/vercel/next.js/issues/15188

`parseRelativeUrl` was used on urls that weren't always relative. It was used to generate a cache key, but we actually don't need these cache keys to be relative if the urls aren't relative.

Also took a look at the overall static data fetching logic and found a few things:

- [x] cache key is unnecessarily transformed through `prepareRoute`, we can just cache by resolved `dataHref` and remove that function. Pretty sure that `prepareRoute` was also introducing edge cases with `assetPath` and `delBasePath`
- [x] there is [a bug in the caching logic](https://github.com/vercel/next.js/blob/ebdfa2e7a3f8e22e03b94dfb5f00481bf06254b6/packages/next/next-server/lib/router/router.ts#L898) that made it fail on the second visit: it should be `Promise.resolve(this.sdc[pathname])` instead of `Promise.resolve(this.sdc[dataHref])`. Also added a test for this
- [x] ~converted to async await to improve stacktraces and readability.~ I assumed this was fine since I saw some async/awaits in that file already but it seems to just blow up the size of the non-modern bundle.
- [x] extracted nested `getResponse` function and define it top level. this should improve runtime performance
- [x] convert `_getStaticData` and `_getServerData` to class methods instead of properties. Not sure why they were defined as properties but I think they belong on the prototype instead.
- [x] remove `cb` property from `fetchNextData`, it's unnecessary and makes the async flow hard to understand.  The exact same logic can go in the `.then` instead.
- [ ] data fetching logic [retries on 5xx errors](https://github.com/vercel/next.js/blob/ebdfa2e7a3f8e22e03b94dfb5f00481bf06254b6/packages/next/next-server/lib/router/router.ts#L157), but not on network level errors. It should also retry on those. It should also not retry on every 5xx, probably only makes sense on 502, 503 and 504. (e.g. 500 is a server error that I wouldn't expect to succeed on a retry)

The overall result also is a few bytes smaller in size

- Introduces a lint rule which points towards the unwanted polyfill.io features.
- Aim here is to make the user aware that which of the requested features are actually required vs which are already covered under `next-polyfills`

Next step: If the remaining required polyfills amounts to a only a few KBs then its better to include them in 1P javascript and remove the third party render blocking script tag.

Next.js forcibly setting `module: 'esnext'` in `tsconfig.json` is necessary to prevent TypeScript from erroring on the following code:

```tsx
import dynamic from 'next/dynamic';

const A = dynamic(() => import('../A'));
```

```
ERROR in /Users/joe/Desktop/scratch/test-cjs/pages/index.tsx(5,25):
5:25 Dynamic imports are only supported when the '--module' flag is set to 'es2020', 'esnext', 'commonjs', 'amd', 'system', or 'umd'.
  > 5 | const A = dynamic(() => import("../test"));
```

However, users may want to use one of the many other targets for better interoperability with projects that co-exist with their Next.js project (like `commonjs`).

When cross referenced with:
```
Option '--resolveJsonModule' can only be specified when module code generation is 'commonjs', 'amd', 'es2015' or 'esNext'.ts
```

That means we can permit any of these values:

```json5
      parsedValues: [
        ts.ModuleKind.ES2020,
        ts.ModuleKind.ESNext,
        ts.ModuleKind.CommonJS,
        ts.ModuleKind.AMD,
      ],
```

This PR updates Next.js to allow those!

---

Fixes #15275

Fixes one of the cases of https://github.com/vercel/next.js/pull/15185#issuecomment-660128647

This matches Next.js engines https://github.com/vercel/next.js/blob/canary/packages/next/package.json#L212-L214

`URLSearchParams` has a `forEach` method. this should simplify and shorten the logic. Perhaps it will even phix https://github.com/vercel/next.js/issues/15232

Co-authored-by: NJoe Haddad <joe.haddad@zeit.co>

This replaces the `url-polyfill` package with the `core-js` version which handles more edge cases in legacy browsers.

Closes #11702
Fixes #15194

Fixes the link rewriting part of https://github.com/vercel/next.js/issues/15194

Co-authored-by: NJoe Haddad <joe.haddad@zeit.co>

Chunks already have a normalized path.

Not sure if there are other chunks that require this change, I did a global search and didn't find similar cases.

This PR corrects the data fetching behavior for optional root routes.

---

Fixes #14923