Add the ability to build an SSC logic tree at runtime to skip XMLs

[CB-quakemodel]

Here I add a new capability in the form of a class called RuntimeSourceModelLT, which is used to build an SSC LT from a builder script provided by the user in the job file in place of the regular SSC logic tree XML (it still uses the source_model_logic_tree_file key):

The builder script provided by the user must contain a top level function called get_source_model_lt which returns a list of triples of (name, weight, xml_str) where xml_str is just a text representation of the info that would be written to disk in an XML.

The RuntimeSourceModelLT ensures that all the regular checks are performed when constructing the SSC LT (e.g. weights sum to 1).

*** GEOMETRY LABEL CTX CACHING ***

An additional (optional) fourth value can be provided for entry in the list returned by the builder script called geom_label. This geom_label is used to group sources with the same rupture sets (i.e., rupture geometries) together. This means we can cache the means and std devs for each GSIM the first time a source with a given geom_label's is admitted into _gen_poes and then avoid the costly compute method. This is a useful feature for supporting the BC Hydro model given it has very heavy branches due to the floating of many hypocentral depths over the embedded faults.

NB: geom_label cache is passable in event-based BUT RESULTS IN NO SPEEDUP because rupture sampling is stochastic per branch so sibling branches do not share an identical rupture set and thus the caching is bypassed (with correct results still observed).

*** TESTS ***

An example application can be found in qa_test_data/logictree/case_34, which includes a builder script constructing a simple SSC logic tree using this approach. Checks in this QA test ensure that identical results are obtained with both full-enumeration and sampling when using an equivalent SSC logic tree constructed from XMLs within classical, disagg and event-based. The geometry label feature is also tested extensively and provides identical results to the no geometry label approach for the classical and disagg_by_src.

There are also unit tests added to ensure other capabilities such as obtaining a composite source model and using to/from hdf5 are supported for RuntimeSourceModelLT + correct use of the geom_label caching capability.

*** IMPORTANT ***

1. This initial approach only accepts one branching level (i.e. you cannot apply epistemic uncertainties using additional branching levels, each branch you wish to describe must be represented by an individual XML, so if you want epistemic uncertainty on dip, you need one xml_str for each dip value).

2. The BASE183 limit is bypassed here (but realisations are still correctly handled and labelled uniquely). This is because RuntimeSourceModelLT accepts an arbitrary number of branches because it bypasses the XML-based SourceModelLogicTree validation that rejects branchsets larger than 183. The branch_path uniqueness problem that would arise beyond this limit is fixed by switching from a BASE183-indexed shortener to one that maps each branch name to itself, with shorten() updated to use the full name rather than just its first character (a check ensures this is only permitted for RuntimeSourceModelLT and also that each name in the list of triples returned in get_source_model_lt is unique as required.

3. Without modification of the classical calculator, the performance implications of having potentially far more than 183 base sources could be significant. This is postulated because of the absence of applyToSources (we cannot use it in the case of BC Hydro due to correlations that must be supported anyway - we need a flat SSC logic tree), which means that within set_num_paths we cannot use the "fast option" because the sources cannot be grouped. Perhaps this is best addressed in a separate PR.

[micheles]

Not what I had in mind, but you cannot be a mind reader. The tests are useful, though.

[mmpagani]

Overall, it looks good to me, and it also gives Michele a bit more time to work on his approach. @micheles, do you prefer to work on this once it's in master or in a branch?

[micheles]

No, it cannot be merged as it is. Hopefully, next week I will have some time to spend on this.