Handle more copy number expression cases

[theferrit32]

Sometimes a copy number variant does not have a name that is in the expected format, and we cannot pull out the required parameters for copy number normalization. Currently we only support absolute copy number forms, so the copy count is required.

Some examples of variants we cannot normalize, expression (and clinvar id):

• NT_187614.1:g.(?_357933)_(2127304_?)dup (32504)
• GRCh37/hg19 1q43(chr1:237413038-237540797) (625614)
• GRCh37/hg19 15q13.2-13.3(chr15:30927362-32929514) (625748)
• NC_000021.7:g.(40550036_40589822)_(46915388_46944323)del (400868)

Attached a more extensive list. Some cover the same case.
unparsed-copy-numbers.edn.txt

[theferrit32]

The CNV handling in the transformer should be expanded to detect whether a variant is an absolute copy number or a relative copy number, and signal to the normalizer which it should interpret it as explicitly. Absolute copy numbers will be those which have a total copy count in the variant name. Those which don't will be interpreted based on ClinVar's variant type field. (copy number gain vs copy number loss). If gain/loss is not specified, will try to use the HGVS expression dup -> low-level gain, and del -> partial loss.

I haven't checked to see whether any relative copy number variants exist in ClinVar which neither specify whether it is a gain/loss in the variant type nor in the HGVS expression.

For absolute copy numbers, will continue using the /parsed_to_abs_cnv endpoint. For relative copy numbers, will use the /hgvs_to_relative_copy_number with partial loss or low-level gain specified. (see: ga4gh/vrs#404)

[theferrit32]

Example of a relative copy number gain with no HGVS expressions, but with gain specified in the variant type:
https://www.ncbi.nlm.nih.gov/clinvar/variation/625614/