Finalize using VV for the creation of all transcripts, now include the mapping of variants.

[ifokkema]

(continuation of #639)
There's one place left where LOVD3 still relies on Mutalyzer for getting transcripts, and that's the automated mapping of variants. VV currently lacks a transcript discovery API endpoint, and transcripts not fully overlapping a variant aren't returned in the LOVD endpoint. So, this remaining feature can only be fixed when VV implements a new API endpoint that allows LOVD3 to discover transcripts overlapping a certain location.

• Use VV to discover transcripts overlapping the region LOVD3 is currently mapping.
• Double-check if variants are fully within the transcript's boundaries.
  • For variants partially outside of a transcript, invent a solution that will allow LOVD3 to store the transcript mapping without breaking HGVS nomenclature rules. This feature may also require more work, as whatever value is chosen should make sure LOVD will never map from that description. However, we're already working on the mapping features in the 3.5 branches, so better not to build something extensive that will cause lots of merge conflicts later on.
  • Consider perhaps incorporating a small piece of code (JSON?) that will render something else depending on the use case; e.g., "(whole gene deletion)" or "(partial gene deletion)" when viewed, but "c.0" or related when exported through APIs? Our HGVS checkers etc should let it pass when it's JSON-parseable? Or just not check?
• Consider selecting only the MANE transcript instead of all transcripts?
• Map the variant to the fully overlapping transcripts using VV's LOVD endpoint, and store the VOT entries.
• Refrain, for now, from removing all remaining Mutalyzer functions. Check if LOVD+ uses them where we don't use them (e.g., the conversion script). In that case, keep the function for now, but document that it should be removed once LOVD+ is updated as well.