docs: fixes misspelling webpack words
uses: `$ git grep -l 'Webpack' | xargs sed -i '' 's/Webpack/webpack/g'`
see:
MODIFY
README.md
README.md
<!-- INTRO START -->
**Rome** is a linter, compiler, bundler, and [more](https://romefrontend.dev/#development-status) for JavaScript, TypeScript, JSON, HTML, Markdown, and CSS.
-**Rome** is designed to replace [Babel](https://babeljs.io/), [ESLint](https://eslint.org/), [Webpack](https://webpack.js.org/), [Prettier](https://prettier.io/), [Jest](https://jestjs.io/), and others.
+**Rome** is designed to replace [Babel](https://babeljs.io/), [ESLint](https://eslint.org/), [webpack](https://webpack.js.org/), [Prettier](https://prettier.io/), [Jest](https://jestjs.io/), and others.
**Rome** unifies functionality that has previously been separate tools. Building upon a shared base allows us to provide a cohesive experience for processing code, displaying errors, parallelizing work, caching, and configuration.

MODIFY
website/src/_includes/docs/intro.md
website/src/_includes/docs/intro.md
<section>
-<!-- GENERATED:START(hash:40beeb5dfdadbfe9ff0e9d1a6b793259b0f8ba23,id:main) Everything below is automatically generated. DO NOT MODIFY. Run `./rome run scripts/generated-files/website-intro` to update. -->
+<!-- GENERATED:START(hash:772ef31658a73dda4b29485f5331384d7980a37e,id:main) Everything below is automatically generated. DO NOT MODIFY. Run `./rome run scripts/generated-files/website-intro` to update. -->
**Rome** is a linter, compiler, bundler, and [more](#development-status) for JavaScript, TypeScript, JSON, HTML, Markdown, and CSS.
-**Rome** is designed to replace [Babel](https://babeljs.io/), [ESLint](https://eslint.org/), [Webpack](https://webpack.js.org/), [Prettier](https://prettier.io/), [Jest](https://jestjs.io/), and others.
+**Rome** is designed to replace [Babel](https://babeljs.io/), [ESLint](https://eslint.org/), [webpack](https://webpack.js.org/), [Prettier](https://prettier.io/), [Jest](https://jestjs.io/), and others.
**Rome** unifies functionality that has previously been separate tools. Building upon a shared base allows us to provide a cohesive experience for processing code, displaying errors, parallelizing work, caching, and configuration.

MODIFY
website/src/blog/posts/2020-08-08_introducing_rome.md
website/src/blog/posts/2020-08-08_introducing_rome.md
@@ -17,7 +17,7 @@ This is the beginning of an entire suite of tools. Rome is not only linter, but
Rome is a [monolithic](https://en.wikipedia.org/wiki/Monolithic_application) tool containing functionality that has traditionally been separate tools in the frontend ecosystem. We call this a toolchain. It is **not** a collection of existing tools, but completely custom, built [largely](/credits) from scratch, contained entirely in a single package and codebase.
-Rome is designed to replace [Babel](https://babeljs.io/), [ESLint](https://eslint.org/), [Webpack](https://webpack.js.org/), [Prettier](https://prettier.io/), [Jest](https://jestjs.io/), and others.
+Rome is designed to replace [Babel](https://babeljs.io/), [ESLint](https://eslint.org/), [webpack](https://webpack.js.org/), [Prettier](https://prettier.io/), [Jest](https://jestjs.io/), and others.
We have significant implementations already for most components, including compiling, bundling, and testing, all using the same core abstractions and internal libraries. Rome is even [self-hosted](https://en.wikipedia.org/wiki/Self-hosting_(compilers)) and we use them to [build and develop Rome itself](https://github.com/romefrontend/rome/blob/main/CONTRIBUTING.md)! Once usage as a linter has stabilized, we will move onto the unreleased features to prepare and generalize them for public usage.
@@ -63,7 +63,7 @@ Even though I wasn't involved in Babel, I still maintained a presence in the dev
The original idea behind Babel had always stuck. What sort of capabilities would be possible if a tool did more than one thing? This sort of philosophy has always seemed alien in the JavaScript ecosystem where micropackages and arbitrary separation of concerns are the norms. These tools being independent has never provided the sort of user autonomy and efficiency that most skeptics of [monolithic](https://en.wikipedia.org/wiki/Monolithic_application) tools proclaim.
-Language tooling maintainers spend so much time working on the same things. Processing source code, whether it's in a transpiler like Babel, linting it in ESLint, or bundling it in Webpack, is fundamentally the same problem with overlapping responsibilities and technical implementation.
+Language tooling maintainers spend so much time working on the same things. Processing source code, whether it's in a transpiler like Babel, linting it in ESLint, or bundling it in webpack, is fundamentally the same problem with overlapping responsibilities and technical implementation.
A linter in the JavaScript ecosystem is exactly the same as a compiler. They both consume code, then produce compiled code and errors. What the compiled code is varies. In the case of a linter, the compiled code is formatted source code with automatic fixes applied. The more powerful your compilation infrastructure, the more theoretically powerful your linter could be. These commonalities extend to pretty much anything that involves language processing. We can build more powerful tools using a shared base that is easily adaptable.

docs: fixes misspelling webpack words (#1084)

uses: `$ git grep -l 'Webpack' | xargs sed -i '' 's/Webpack/webpack/g'`

see: https://webpack.js.org/branding/#the-name

Signed-off-by: Antoine Leblanc <ant.leblanc@gmail.com>