fix: making the TSSDistance behaviour consistent

[DSuveges]

The problem

Currently if users extract distances from TSS for both directions (-plugin TSSDistance,both_direction=1), the value of downstream distances are negative. This behaviour is not consistent how distance is reported, where all reported distance is positive irrespective if the variant is up or downstream.

This PR allows users to provide and extra parameter to the TSSDistance plugin (signed_distance=1), which would allow for negative values, otherwise (by default) only positive distance is returned.

Testing

I picked "chr4:1804392 G/A", a missense variant for testing, which has a downstream position from the TSS of the overlapping gene. What I got with different runs:

1. --plugin TSSDistance: no tss distance is in the output, as the default behaviour prevents that.
2. --plugin TSSDistance,both_direction=1: "tssdistance": 11099 positive distance however downstream position.
3. --plugin TSSDistance,both_direction=1,signed_distance=1: "tssdistance": -11099, the distance value is signed.

Please take a look and let me know if there's something wrong with my thought process.

[jamie-m-a]

Hi @DSuveges

I'm fine with having this plugin use absolute distance for upstream, but we generally do not alter default behaviour where possible (people build things in to pipelines, changing defaults can have impacts). So I would suggest that both_direction retains it's original return of upstream having a negative sign. Then, instead of having the signed_distance param, swap this for absolute_distance. Then both_direction + absolute_distance would = TSSDistance => abs($dist)

[DSuveges]

Hi @jamie-m-a , thanks for the review! Actually I 100% agree, the reason behind the above default implementation was to mimic how the transcript "distance" is reported, which is a positive number regardless being up or downstream variant. I'm very happy to change the behaviour in the PR!