Make all damage variables the same sign

[corakingdon]

@davidanthoff Based on our conversation last week, I've attempted to make FUND have consistent signs for all of the damage variables, where a positive value means damages, and a negative value means benefits. This means that the ImpactAggregation component simply sums together each damage variable to calculate eloss, without having to change any signs.

The five variables I had to switch were:

• agcost in ImpactAgriculture
• cooling in ImpactCooling
• forests in ImpactForests
• heating in ImpactHeating
• water in ImpactWater

Questions:

1. These variables were previously measuring "impacts". Now that they are measuting "damages," would you prefer for me to rename them to match the other damage variables, such as waterdam or watercost to be consistent? (it's confusing that the agriculture one is already called agcost, even though it was measuring benefits.)
2. To make this switch, I simply multiply by -1 in each of the damage components' run_timestep functions (slightly more complicated in the Agriculture component, but you'll see that that's basically what I did). But would you prefer something more sophisticated, where we actually just change the sign of the "benchmark" parameter for each component, so that it has the correct sign instead?
3. The forestry, water, and agriculture components all had min's that I've now changed to max's which limit the size of the benefits to all or some fraction of the economy. I still think this is confusing, and just want to check that this isn't a bug that we should address. If not, can we add something to the documentation that explains how these ceilings on sector-specific benefits were picked? (for agriculture, benefits can't exceed the agricultural share of the economy. for water and forests, the limit on benefits is 10% of income)
4. I started trying to update the docs to reflect this switch. I think that the Agriculture and Cooling docs were previously erroneous, saying that the variables already represented damages, when I think they did not, but would like your confirmation of that!

[corakingdon]

So a lot of the validation tests are failing, clearly something I changed must not be quite right! Visually, if I use explorer on a v3.11.9 version of the model and on this switched version, each of these variables looks right, so it's nothing glaringly wrong. But I've looked over the code several times and can't figure it out.

[corakingdon]

to do:

1. I'll rename the variables to have "dam" suffix
2. leave -1's as is
3. don't address min/max things in this PR
4. @davidanthoff will review my updates to the documentation to confirm I've got it right

David will try looking at the code to see if there is anything obviously wrong, if he can't find the problem, then I will try to test the changed components out one by one.