Add ability to run the reference proteome step on the full peptide sequence in a fasta

[malachig]

In general there is quite a lot of interest in having better integration of the long-peptide forms. Everything in our epitopes results files and pVACview is focused on the predicted binding peptide. And this makes sense. But it would also be really helpful to consider factors in the context of the longer peptide that harbors the core peptide such as:

• Are there problematic amino acids flanking the core binding peptide that would make solubility/stability a concern?
• Are there reference similarity issues?
• Where are the predicted cleavage sites in the long peptide relative to the short peptide?
• How do the position of the predicted class I and II peptides relate to each other?
• Are there nearby splice sites that influence the peptide sequence of the long peptide? Potentially giving rise to multiple competing representation of a long peptide that contain the same short peptide?

[susannasiebert]

Current pVACseq runs already saves a peptide fasta (albeit only with a flanking length of max(epitope_lengths) - 1), which we use for a lot of these steps. I think this would require us to implement another parameter "vaccine candidate length" or similar to create a fasta with even longer lengths.

This could then be easily used for running:

• reference proteome analysis
  • we'd need to decide how to handle the false positive hits we'd get here
• problematic positions
  • we could already use the current fasta for that, but the "vaccine candidate fasta" would be better.
  • do we want to differentiate between problematic positions in the core peptide vs non-core amino acids?

For cleavage site predictions we need an additional 10 aa flanking length on top of the desired vaccine peptide length (see #615)

I almost envision a separate report for this that wold enumerate vaccine peptides and the issues identified above. This report could also include the Best Peptide for class I and class II. I'd have to think a bit more about how we could report the alternate splice sites.