Support for 'N' bases

[brendanofallon]

I'm seeing an error that looks like it involves 'N' bases (see stack trace below). Not sure if the Ns are in the ref genome (we're using b37) or the BAM file, but either way this is a showstopper since we can't guarantee that either will never have a N.

Here's the stack trace:

Traceback (most recent call last):
  File "/opt/clair/clair/../clair.py", line 93, in <module>
    main()
  File "/opt/clair/clair/../clair.py", line 87, in main
    submodule.main()
  File "/opt/clair/dataPrepScripts/ExtractVariantCandidates.py", line 450, in main
    make_candidates(args)
  File "/opt/clair/dataPrepScripts/ExtractVariantCandidates.py", line 290, in make_candidates
    base = BASE2ACGT[SEQ[query_position]]
KeyError: 'N'

Really awesome work otherwise! I think your approach has a lot of advantages over the DeepVariant method (which seems a lot just like an improved VQSR), I'm pretty excited about Clair in general!

[chaklim]

Right now treated 'N' bases as 'A'
and going to create an option to handle those IUPAC bases