Clip bam to bed output values using input values from chrom.size file

[donaldcampbelljr]

I have this file UMGC-Mod-084-1s-MN24-d1-D_S44_sort_dedup.bam which does not produce the issue. It appears that the failing file is UMGC-Mod-084-1s-MN09-d1-A_S1_sort_dedup.bam.

Regarding the bed file's last row extending beyond the chrom size, I think that is unrelated to this issue, but we should clip it in the bam_to_bed_no_counts based on input chrom.sizes like we do in the other counting functions.

@nleroy917 Good idea. By the time the program gets this far, it has checked that the chromosomes exist in the bam file. However, it could raise an error during writing to the bed file line by line, but we should see this error in the terminal (which I don't in this case). We could skip that file. As long as the program communicates that it was expecting a chromosome file but didn't find one that would be fine. Currently, the messaging is inadequate either way as I'm not sure which chrom failed from the backtrace. :) Also, I would think the consumer handle would produce an empty file either way by this point.

Originally posted by @donaldcampbelljr in #74

[donaldcampbelljr]

The original bamsitestowig did not clip this output and would happily create a bed output that extends beyond the chromosome size. Should we actually implement this?