The HaplotypeCaller read filter status indicator should include the number of un-filtered reads for comparison

[jamesemery]

I have noticed after looking at the HaplotypeCaller command line in some recent forum posts (https://gatk.broadinstitute.org/hc/en-us/community/posts/7293912288795-Haploytpe-caller-shows-me-that-0-read-s-were-filtered-by-MappingQualityAvailableReadFilter-etc) that the output of the filtering summary can be confusing if a lot of reads were processed. It can be very useful to know that a lot of reads are lost to a particular filter as an important sanity check for processing but unfortunately that information can be very confusing and not helpful without some indication of the total number of reads that were processed to begin with. I propose that we add to the CountingReadFilter code additional logic to keep track of the unfiltered reads as well so we can report both numbers to the user and clear up potential confusion.