check SAMRecords' "read unmapped" flag

seems like something we should be looking at when parsing SAMRecords

also a few random other cleanups / nits

this builds on my [other PR](https://github.com/hammerlab/guacamole/pull/152) that splits up `Read.scala`, so diffs may be cleaner once that one has happened.
yea, this was a little tricky. summary:
* there are 8 total reads in [mdtagissue.sam](https://github.com/hammerlab/guacamole/blob/master/src/test/resources/mdtagissue.sam)
* reads [#1](https://github.com/hammerlab/guacamole/blob/master/src/test/resources/mdtagissue.sam#L9) and [#3](https://github.com/hammerlab/guacamole/blob/master/src/test/resources/mdtagissue.sam#L11) have the `0x4` "unmapped read" flag set (flag field values 101 and 133, resp.), so there are only 6 mapped reads.
  * incidentally, they are also the only two missing MD tags, which is the other filter applied on line 12 above, so the arguably wrong mapped-ness value we were computing was being masked by that filter.
* reads [#2](https://github.com/hammerlab/guacamole/blob/master/src/test/resources/mdtagissue.sam#L10) and [#5](https://github.com/hammerlab/guacamole/blob/master/src/test/resources/mdtagissue.sam#L13) have the "duplicate" flag `0x400` set (flag values 1097 and 1177, resp.), so they get dropped in this check as well. Previously, #1 and #3 were passing the "mapped" filter, but now they are not, meaning now we are dropping two non-mapped reads and two duplicate reads, instead of just two non-duplicate reads.