docs(guides): Small readme improvements, remove the word "simple" (#2671)

* Small readme improvements, remove the word "simple"

Most of us are reading the docs because we don't know how to do something, and it's not fun to hear that the concept we're having a hard time understanding is "simple" or "easy". I'd love you to show me how simple it is instead. 

A great reference: https://css-tricks.com/words-avoid-educational-writing/

Updated some language around `contenthash` as well, hopefully it's a little more direct. Let me know what you think.

* Switch "Webpack" (caps) to "webpack" as per brand guidelines

* Use webpack doc standard bold indicator

* Remove "However" statement in caching page

Weasel word, and the statement doesn't really give value.

Author: robwierzbowski

src/content/guides/caching.md

@@ -25,7 +25,7 @@ This guide focuses on the configuration needed to ensure files produced by webpa
 
 ## Output Filenames
 
-A simple way to ensure the browser picks up changed files is by using `output.filename` [substitutions](/configuration/output#output-filename). The `[hash]` substitution can be used to include a build-specific hash in the filename, however it's even better to use the `[contenthash]` substitution which is the hash of the content of a file, which is different for each asset.
+We can use the `output.filename` [substitutions](/configuration/output#output-filename) setting to define the names of our output files. webpack provides a method of templating the filenames using bracketed strings called __substitutions__. The `[contenthash]` substitution will add a unique hash based on the content of an asset. When the asset's content changes, `[contenthash]` will change as well.
 
 Let's get our project set up using the example from [getting started](/guides/getting-started) with the `plugins` from [output management](/guides/output-management), so we don't have to deal with maintaining our `index.html` file manually:
 
@@ -91,7 +91,7 @@ W> Output may differ depending on your current webpack version. Newer versions m
 
 ## Extracting Boilerplate
 
-As we learned in [code splitting](/guides/code-splitting), the [`SplitChunksPlugin`](/plugins/split-chunks-plugin/) can be used to split modules out into separate bundles. webpack provides an optimization feature which does split out runtime code into a separate chunk(s) according to the options provided, simply use [`optimization.runtimeChunk`](/configuration/optimization/#optimization-runtimechunk) set to `single` for creating one runtime bundle:
+As we learned in [code splitting](/guides/code-splitting), the [`SplitChunksPlugin`](/plugins/split-chunks-plugin/) can be used to split modules out into separate bundles. webpack provides an optimization feature to split runtime code into a separate chunk using the [`optimization.runtimeChunk`](/configuration/optimization/#optimization-runtimechunk) option. Set it to `single` to create a single runtime bundle for all chunks:
 
 __webpack.config.js__
 
@@ -339,4 +339,4 @@ We can see that both builds yielded `55e79e5927a639d21a1b` in the `vendor` bundl
 
 ## Conclusion
 
-Caching gets messy. Plain and simple. However the walk-through above should give you a running start to deploying consistent, cacheable assets. See the _Further Reading_ section below to learn more.
+Caching can be complicated, but the benefit to application or site users makes it worth the effort. See the _Further Reading_ section below to learn more.