Review redundancy in distance calcualtions/PropEffect

[Peter Powers]

For each calculation in Campbell & Bozorgnia (2008), once a site is set, the PropogationEffect? is reset, then rRup and dist_jb are retrieved via parameter name string comparisons. (At this point distSeis is unnecessarily calculated in PropEffect?). distRupMinusJB_OverRupParam is set via:

distRupMinusJB_OverRupParam.setValueIgnoreWarning((rRup-dist_jb)/rRup)

Once the calculation starts, BOTH getMean() and getStdDev() (re)calculate/derive rJB via:

rJB = rRup - distRupMinusJB_OverRup*rRup;

Before passing the rJB value off to the heavy lifting versions of getMean() and getStdDev() where the hanging wall effect is then calculated again via:

fhngr = (rRup-distJB)/rRup;

[Kevin Milner]

The main distance calculation redundancies were addressed in other tickets. The remaining one outlined here, duplicate rJB calculation is very minor (just a couple floating point arithmetic operations). I think that the added overhead and complexity of updating the primitive rJB whenever a distance parameter is updated (whether it's via setSite/setRupture or directly such as in the AttenuationRelationshipGUI) outweighs the benefits of removing this redundant line of code. I made rJB private in [10928] to make it more clear.