Bug: Y-Intercept output incorrect if signal polarity option (-1) is used

Description

A part of the PyRate output is a GeoTIFF of Y-Intercept values (linear_intercept.tif) for each pixel to accompany the GeoTIFF containing rate values estimated by PyRate from the per pixel cumulative time series.
There is an option in PyRate configuration file to reverse the sign of the line-of-sight values so that the time series makes physical sense signal_polarity: -1.
The signal polarity change occurs in the MERGE step and seems to operate only on the time series data and the rate output but not on the Y-Intercept output.
This means that when users are plotting PyRate results, there is a mismatch between the Rate and Y-Intercept.

Expected Behaviour

When the signal_polarity: -1 option applied, the change of sign should work consistently across all outputs.

Testing

Here I compare the rate and y-intercept estimate produced from PyRate processing with the values produced independently on the cumulative time series.
Both operations use the same method to estimate rate and y-intercept scipt.stats.linregress() .
Note the sign change of y-intercept.

SciPy Rate: -223.43657517299133 SciPy Y-Intercept: -28.24114861088961

PyRate Rate: -223.4365692138672 PyRate Y-Intercept: 28.24115562438965

Action

This will be a small PR job that investigates the best way to resolve this.
This also indicates that our tests have not picked this up.
Most likely looking into the below function where the sign change operation occurs in the MERGE step (line 325).

Visuals

What we should see:

What PyRate produces:

GeoscienceAustralia / PyRate