Improve coverage testing and filesystem coverage

[JMicheli]

This pull request is a bit of a grab-bag of testing improvements. I'll describe them in three categories: 1) code coverage tooling, 2) new testing data, 3) new tests.

Code coverage tooling

Since I've been making some tests additions, I thought it would be nice to start using some tools to track how that was going. I found cargo-llvm-cov and it seems perfect. It runs all tests and generates a file that a gutters extension in VSCode can use to give visual feedback on what lines of code are being tested.

To support this, I added a tasks.json file, and added a task that automatically runs the command to generate lcov.info (which I added to the .gitignore). I also added a setup task for good measure since I always find myself running that.

New testing data

I wanted to add some more file tests, so I added some new testing data alongside the other data in integration-tests (I would like to clean that up sometime and get it working again). Everything I added is public domain, and includes a webp image from Google, a cbz comic I got from a public domain comic archive, and a PDF copy of the rust book.

New tests

I added tests to various filesystem modules that used the aforementioned data to make sure various processing functions worked. I don't have total coverage in each module yet because certain things were harder to test than others. But it's a start!

I also added tests for the webp module, and I found that I had no issue passing when I loaded the data from the file as a Vec<u8> and passed it to the processor, but that when I used the function to open a path it would fail. I think there was something wrong with the way data was being loaded there, so I changed it to a simple fs::read(path) and it seemed like that did the trick. But maybe I misunderstood the reasoning for the way this was originally written - please take a look at that and confirm that what I've done works.

[aaronleopold]

LGTM! Thank you for tackling all of these testing improvements!!

I think there was something wrong with the way data was being loaded there, so I changed it to a simple fs::read(path) and it seemed like that did the trick. But maybe I misunderstood the reasoning for the way this was originally written - please take a look at that and confirm that what I've done works.

To be honest, I can't recall why I chose the image::io::Reader. If I had to guess, I likely assumed that the reader would have extra utilities baked in for facilitating image decoding/encoding. Your logic is sound, though, and I have no objections to keeping it as you made it 👍

[JMicheli]

Addressed comments, ready to merge.