fix RelativeLocation.getLocation(Loc, Dir) sign problem

[Peter Powers]

RelativeLocation?.getLocation() does not treat Direction as a vector and changes the sign of the depth component.

Facts:
'Direction' is a vector; which way is up is irrelevant.
Seismology, and hence OpenSHA, treat depth as positive down.

Notes:
Everywhere in the code, tests, etc..., depths are entered as positive values. Perfect.
Dir1 = RelativeLocation?.getDirection(Loc1, Loc1) returns the correct vector [i.e. for Loc1(D1=2) and Loc2(D2=4), dV = D2-D1 = 2]
The expectation from vector math is that Loc1 + Dir1 = Loc2. However, RelativeLocation?.getLocation(Loc, Dir) does NOT produce this result. Rather than adding the depth component of the Dir1, it subtracts it (D2 = D1-dV = 0). This is wrong.

Why the problem hasn't presented itself to date:
Every call (~71) to RelativeLocation?.getLocation(Loc, Dir) that is interested in depth makes up for this error by switching the sign at some earlier point. As an example, when initializing a StirlingGriddedSurface? the vector from the trace to top of seismogenic rupture is computed as:

vDistance = traceLocation.getDepth() - upperSeismogenicDepth;

vDistance is negative and should be positive:

vDistance = upperSeismogenicDepth - traceLocation.getDepth();

but the sign switch acoomodates the error in getLocation(). Subsequently, the vectors to each down dip node are computed as:

vDistance = -ith_row * gridSpacingSinAveDipRadians

Again, in this case, the sign of ith_row has been changed to accomodate getLocation().

Conclusion:
Change getLocation() and all affected calls (fewer than than the total 71) on the GEM branch for future merging. This won't take too much work and will prevent further confusion.