* add a regression test comparing the manual Perl-based
single-file filtering prior to accumulator API usage vs.
the current Python "API" equivalent

* we'll probably want documentation demonstrating this as well,
but the regression test is probably higher priority in the short
term

* note also that we would currently place the burden of expanding
the dataframes to include the file paths/names proper up to the end user
(currently only have columns with the `id`/hash) if they wanted to
filter by regex; that said, we do have library functions that do this
kind of thing internally anyway... all of this is to say that just
writing this test will probably expose some design thinking, or at least
reveal some of the more complex things we may want in our docs for
filtering in Python route

* finally, note that Phil C. did forward a C program and some other
assets for developing a test like this; however, it is far easier
for me to just perform the steps manually on log files that are already
in the logs repo (that was kind of what I was hoping for--expected
values for counters/derived metrics given a log file and a single file
hash, but I've just gone ahead and pulled them out myself)