Parse single breakends and large insertion shorthand notation

[cmdcolin]

Parses G. and G<ctgA> more correctly, producing respectively

{
  "Join": "right",
  "Replacement": "G",
  "SingleBreakend": true,
}
 // just ends after G, it is a "single breakend" a la 5.4.9 https://samtools.github.io/hts-specs/VCFv4.3.pdf so we have no Mate

{
  "Join": "left",
  "MateDirection": "right",
  "MatePosition": "<ctgA>:1",
  "Replacement": "G",
}
 // a large insertion of ctgA to the right of G

On current master, G. and G<ctgA> parses as undefined

[codecov]

Codecov Report

Merging #95 (9b41749) into master (ed6207c) will decrease coverage by 0.70%.
The diff coverage is 89.47%.

@@            Coverage Diff             @@
##           master      #95      +/-   ##
==========================================
- Coverage   97.43%   96.72%   -0.71%     
==========================================
  Files           3        3              
  Lines         195      214      +19     
  Branches       69       80      +11     
==========================================
+ Hits          190      207      +17     
- Misses          5        7       +2     

Impacted Files	Coverage Δ
src/index.ts	94.59% <89.47%> (-5.41%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[cmdcolin]

could have implications on consumers perhaps since we make MatePosition/MateDirection nullable, but it seems like the "right" behavior since there is no mate

[cmdcolin]

note that the shorthand G<ctgA> is the same as G[<ctg1>:1[ from my understanding, so it parses to the same thing in this PR

[cmdcolin]

fixes #84

[cmdcolin]

I also removed what may be an invalid single breakend in our tests

We tested for a breakend looking like this .[13:123457

This doesnt look valid however, I can restore it if there is evidence that this is valid though

[cmdcolin]

this PR does not have any conflicts with jbrowse-components type wise, might be good to go