Introduction of logic trees for the site model

[CB-quakemodel]

Currently the engine does not support logic trees for the site model (e.g., different Vs30 or k0 values to represent epistemic uncertainty in the site conditions).

---

An initial approach was proposed in #11650 - which was to incorporate epistemic uncertainty in the site parameters within the GMM logic tree (i.e., same GMM, but different site params per branch of the GMM logic tree, with weight per branch needing to represent the product of GMM weight and site parameter weight). This approach was simple to implement and required few file changes, but it had some downsides:

1. It meant that the modelling of epistemic uncertainties related to site parameters was being buried implicitly within ModifiableGMPE, which is a (very large) GSIM module, rather than being handled explicitly in dedicated modules and classes. Site model logic trees are a key component of a hazard model and therefore require dedicated containers.
2. It also meant that we could only assign a uniform modification to each site in a site model, and therefore it was only useful for site specific studies, in combination with additional (to be added as required) ModifiableGMPE capabilities to support selected site response methodologies.
3. Finally, it meant that we had to repeat modifications across each GMM used in the GMC logic tree to obtain consistency of the site parameter uncertainties over the models, which was inefficient.

---

Therefore, a containerised approach where the epistemic uncertainty on the site model is explicitly handled (including sampling and full enumeration with all sampling methods) in distinct classes and modules was deemed more appropriate. An initial implementation of this approach is provided in #11654.

One key choice made in this initial containerised approach PR, was following some discussion, to make the site model logic tree (a NRML 0.5 XML like used for the SSC and GMC) to point towards regular site model files (either XML or CSV format) each with an associated weight. The alternative approach was to specify "base sites" in a list, and then modifying them in ways similar to how the "base sources" in an SSC logic tree can be modified using capabilities like applyToSources or applyToBranches. The former approach of pointing toward different site model files in the XML file was chosen primarily because:

1. Given a site model can contain many (potentially hundred of thousands) of sites if we are considering a regional scale assessment (e.g., a user might wish to consider different Vs30 models that are available for a regional scale study), the approach of pointing toward different site model files seems preferable - it allows the explicit specification of each site's parameters in a given branch of the logic tree using the existing site model schema, and works for either a single/few site analysis, or a regional scale analysis. Using an XML logic tree containing "base sites" and then applying relative or absolute uncertainties to a site model would quickly result in very large and complex site model logic trees if there are many sites with non-uniform per-site adjustments, and can be handled more cleanly by pointing to different site models with explicitly provided values per param instead.
2. This approach also readily allows the specification of correlated uncertainties on site model parameters by only building the site models containing the combinations of parameters you want to represent in the site model logic tree.

---

Some key points regarding approach implemented in #11654

• A new hazardlib module site_lt.py handles the site-model logic tree through two containers: SiteModelLogicTree (parses and validates the site model LT XML) and SiteModelsEpistemic (holds the loaded per-branch site model arrays and handles sampling).
• The user can specify a site model XML file for the site_model_file key in the .ini within which each branch points to a different site model (either CSV or XML version).
• The site models must have identical lon/lat (and elevation if present), although the site IDs can vary (useful for tracking site param diffs at same locations) and share all site parameters (but of course the values for each parameter within each site model can differ). An error is raised by the engine if the lon/lat/potentially elevation is not consistent across the site models.
• Full enumeration and sampling are supported with both early_weights and late_weights.
• Full set of QA tests using full enumeration, sampling, late and early weights for classical and disagg calcs
• Unit tests for the new site_lt.py hazardlib module (site_lt_test.py).
• There are only changes to a handful of existing modules - the bulk of the "files changed" are new QA test files or documentation-related.
• The existing override_vs30 .ini option added for AELO is a different feature altogether - it computes hazard curves for each required Vs30 but does not then combine them into a single distribution of curves per site and IMT (as would be the case in a true logic tree approach).

---

To-Do:

• Agree upon the initial implementation for classical and disaggregation (this is where it is most needed in the short term given upcoming projects).
• If agreed upon, expand the feature to the other calculators. Event-based in particular will need discussion given how the sampling works here.

Any feedback on this is of course welcome. I think the priority is for now is completing a working (and agreeable) implementation for the classical and disaggregation calculators.