Add multiple hosts

[wenzeslaus]

Steps:

• [x] Create multi-host object
• [x] Use multi-host in run_step
• [x] New API run_step
• [x] competency
• [x] susceptibility scores (part of pest-host-use table)
• [x] susceptibility for individual hosts
• [x] multi-host C++ test
• [x] competency C++ test
• [x] test expected infected in C++ tests
• [x] multi-host mortality (part of pest-host-use table)
• [x] susceptibility scores C++ test
• [x] treatments
• [x] spread rate
• [x] quarantine
• [x] overpopulation
• [x] host movements (for one host only)
• [x] add parameters for multiple hosts (pest-host-use table)
• [x] add parameter for pest versus pathogen
• [x] implement pest landing
• [x] documentation
• [x] revisit disperser_to behavior for one host and no S (does std::discrete_distribution eat random numbers for {0}? no, but it does for {0,0}) (Edit: It turns out, it eats them on macOS.)
• [x] hide Environment::add_host call in HostPool constructor
• [x] allow access to dispersers through PestPool so that run_step does not need to take that parameter
• [x] Add RasterIndex to HostPool to avoid it in CompetencyTable template parameters
• [x] Fix conditional jump based on uninitialized memory
• [x] check speed issues (e.g. map versus sequential lookup - complete versus partial competency table)
• [x] Rename establishment probability to better fit with its usage and suitability/susceptibility score.
• [x] Remove extra usage of random number (applies on macOS)
• [x] Benchmark multi-host case full versus partial competency table for one host (no difference).

Future work:

• Benchmark multi-host case full versus partial competency table for many hosts.
• Profile all code.
• Consider precomputed raster for competency.
• Revise use of C++ API for random number generators and distributions.

[wenzeslaus]

I updated the description with the current plan. The failing tests are caused by not implementing overpopulation and treatments in the model.

[wenzeslaus]

Replacing HostPool::establishment_probability_at() by HostPool::suitability_at() with enforcement of <=1 condition:

-            double s_for_item = host_pool->establishment_probability_at(row, col);
-            // The resulting s can be 0-1. While the probabilities are used as weights
-            // for picking the host, so their absolute range does not matter, the total
-            // is used as probablity in a stochastic test. The stochastic challenge may
-            // be against 0.5 + 0.7 = 1.2 which which is fine as long as we are fine
-            // with probabilities 0.5 and 0.7 from two host translating to 100%
-            // probability.
-            probabilities.push_back(s_for_item);
-            total_s_score += s_for_item;
+            double suitability = host_pool->suitability_at(row, col);
+            // The resulting individual suitability can be 0-1. The indivudual
+            // suitabilities are used as weights for picking the host, so their absolute
+            // range does not matter. The total is used as probablity in a stochastic
+            // test and should be <=1 which will be ensured in the input data.
+            probabilities.push_back(suitability);
+            total_suitability_score += suitability;
         }
-        if (total_s_score <= 0) {
+        if (total_suitability_score <= 0) {
             // While the score should always be >= 0, it may be == 0 if no hosts are
             // present. No hosts present cause all probabilities to be zero which is not
             // permissible for the host picking later and it is enough information for
             // us to know there won't be any establishment.
             return 0;
         }
+        if (total_suitability_score > 1) {
+            throw std::invalid_argument(
+                "Total suitability score is " + std::to_string(total_suitability_score)
+                + " but it needs to be <=1");
+        }