Download the HTML for the page when screenshotting

[BryceStevenWilley]

IMO it's best to think of it as a part of the screenshot (enhanced screenshot). We also replace relative URLs for CSS / JS with absolute URLs, adding the server url in front of them. This isn't perfect, as CORS will prevent the page from fully loading, but it's close enough, people will still have the screenshot if they want exactly what the page looked like.

Fixes #763, probably some other related ones as well.

In this PR, I have:

• [x] Added tests for any new features or bug fixes (if relevant) (no existing tests for ensuring JPGs are saved, not sure how to write them)
• [ ] Added my changes to the CHANGELOG.md at the top, under the "Unreleased" section (have avoided doing so until we're ready to merge, to avoid merge conflicts with other open PRs)
• [x] Ensured issues that this PR closes will be automatically closed

Any manual testing I have done to ensure my PR is working

Have manually run the tests, and have made sure that:

• all screenshots have a partnering HTML page
• said HTML page mostly loads in Firefox. See issues with CORS mentioned above

[BryceStevenWilley]

Confirmed that the HTML files are uploaded correctly!

[BryceStevenWilley]

From synchronous discussion: we aren't sure how much performance gain we get from the Promise.all stuff, and it's a bit easier to read/ maintain without it, so going to remove that.

[BryceStevenWilley]

The HTML also comes out a bit weird (I looked specifically at the upload page where there were doubled fields and such)

Yeah, I mentioned that in passing earlier, but most of that is because the javascript on the page can't run. Loading a webpage from a local file that then tries to call a docassemble server will fail for several cascading reasons:

• sometimes the JS on the page calls back to relative links on the server, so loading the file off of the server breaks those links
• The server won't know what interview is occuring when you load the page from a different browser, so most of the JS calls will still fail
• Finally, sometimes the JS will make POST calls, which need to have CORS (Cross Origin Resource Sharing) rules enabled. Most browsers won't let you set those rules properly when opening files locally in your browser, for security reasons.

But I agree that it's good enough. Just saying that "it'll be different, still use the screenshots, and only look at the page if something's missing in the screenshot, or you need to examine the HTML code directly (opening in the browser to use inspect tools is helpful here)" should be enough. I'm gonna document a lot of other stuff tomorrow, I'll try to do this one as well.