Webpack build/serve compressed bundle files

We use webpack to create three js bundle files on build:
- runtime.bundle.js
- main.bundle.js
- vendors.bundle.js

See PR #346 for context.

These are served via straight hyperlinks on the one html file which django serves and react uses as a base for everything else:
https://github.com/DemocracyLab/CivicTechExchange/blob/7d28862876c0142e0dc0f8957fd44b76b3a1b7eb/civictechprojects/templates/new_index.html#L16-L18

However, we are not (apparently?) using gzip or brotli or any compression. According to heroku, [that's our app's responsibility](https://devcenter.heroku.com/articles/compressing-http-messages-with-gzip) and we're getting rightly knocked in Lighthouse reporting for not doing this.

Therefore: in order to reduce initial load time and transfer, we should offer compressed bundles. Gzip, at minimum. Webpack should be able to build them as part of `npm run build` though there are plenty of other options. Then, we need to offer the compressed version to any browser requesting it with the uncompressed bundles as fallback options. Right now the app doesn't appear to care if an http request has `Accept-Encoding:` because we don't have any encoded bundles to offer and don't have a way to send them since the hrefs are just hrefs.

As you can see in the lighthouse report I posted our compiled sass styles.css file is also something we can offer this way and I'd like to see that too, but the bundles are a higher priority.

To sum up,
- generate compressed bundle files in some form or another for us to use
- serve these if the http request has the appropriate accept-encoding header
- serve uncompressed bundles as fallback if needed
- don't break anything ;)

We probably don't need to generate compressed bundles with the `dev` build script -- that doesn't get used on production -- but `build` should do all this. I also may not be describing this very well - so there may be some research needed before implementation if I'm missing something in this ticket.