Finish Upgrading Webpacker to v5

[DeeDeeG]

Context

• Follow-up to deps: Upgrade @rails/webpacker to v5.x #634
• Upgrade thewebpacker gem to v5, and update the related config files; Bump the webpack-dev-server JS dependency to a new minor version.

Summary of Changes

• Gemfile[.lock]: Bump the webpacker gem to version 5.2.1 (~> 5 semver range).
  • Update various config files to the new default configs as of webpacker 5.2.1
• package.json, yarn.lock: Bump webpack-dev-server from 3.9.0 to 3.11.0 (^3.11.0 semver range).

Checklist

• Tested Mobile Responsiveness
• Added Unit Tests
• CI Passes
• Deploys to Heroku on test Correctly (Maintainers will handle)
• Added Documentation (Service and Code when required)

[DeeDeeG]

Planning to merge this today, and then re-work #636 on top of this.

This Pull Request incidentally makes sure we can install JS dependencies with custom resolutions (a Yarn feature). Which will be helpful for #636.

(Without that, and taking advantage of the custom Yarn dependency resolutions, we would be unable to run Refuge locally/in Docker under the development Rails environment setting. There would be a complaint about "Your Yarn packages are out of date! Please run yarn install to update."

The "integrity check" is something the Yarn developers advocate not doing, because it's old, deprecated code, and the checks it does aren't really necessary. It's dropped from the next major version of Yarn, Yarn 2.0. If you have a lockfile, as we do at this repository, the proper way to do this would be yarn install --frozen-lockfile. For more details about why webpacker dropped the dubious "integrity check", see: rails/webpacker#2518)

[DeeDeeG]

Also commenting this for the record:

There is a proper process to upgrade Webpacker (as others have done before at this repo). For the sake of documenting this, the proper process is:

• Upgrade the webpacker Ruby gem in Gemfile and Gemfile.lock.
• Run rails webpacker:install
  • Review any conflicts in the files updated during this process.
    • If we do something custom at our repository, determine why we deviated from the defaults, and if we need to keep the custom behavior or can drop it in favor of the defaults.
    • Reviewing the webpacker changelog can be helpful for determining which changes were in the webpacker gem itself, versus changes developers at this repository deliberately made. https://github.com/rails/webpacker/blob/5-x-stable/CHANGELOG.md
  • The rails webpacker:install process also upgrades @rails/webpacker in package.json and yarn.lock. Review these updated JavaScript dependencies and see if it is done right, or if you would have done it differently.
    • For example: when I was working on this pull request, the rails webpacker:install process upgraded @rails/webpacker to an exact version, whereas I prefer to use caret ^ server ranges (which means "allow updated versions greater than or equal to the specified version, but only allow updates from the same major version.").