Hybrid storage for penetrance

[XingerTang]

In PR #292, some attempts have been made to optimise the memory usage.

A hybrid (sparse + dense) storage of penetrance is attempted, but the code change would not be pushed here.
The idea is that individuals have a mix of HD and LD genotypes input. For the LD individuals, the massive missing values of LD individuals would be read into the penetrance and would take up a lot of space.
While the penetrance is generally not updated if est_geno_error_prob and est_seq_error_prob are not used, it is easy to find that if we use sparse storage, then a large portion of the memory space of penetrance probability can be saved.

In the simulation data, there are 1500 LD individuals with 100 loci data.

An estimate of the full dense storage of penetrance probability for LD individuals is:

$$ 1000 \times 4 \times 2000 \times 4 = 3.2 \times 10^7 $$

While the estimate of the sparse counterpart is:

$$ 1501 \times 4 + 1500 \times 100 \times (4 + 16) = 3 \times 10^6 $$

The memory profiling also suggests a 20 MB reduction in the memory usage of the default runs after using hybrid storage.

Yet, there are a lot of code additions and therefore not fit to the purpose of this pull request ("refactoring").
Also, the performance is unstable for the case requiring an alternative allele frequency update after the first peeling cycle, which requires access to penetrance data.

This can be a direction for future work.

[gregorgorjanc]

If we would have a fully revolved case of recombination/segregation, then we would only have to write out where recombinations happened, which would be very sparse - that's the idea of tree sequence / ARG - there we write the edge table where edges represent links between a haplotype and its immediate ancestors (haplotypes) plus start and end of the shared/transmitted area. With Oregon colleagues we discussed that we could encode uncertainty of where recombination happened by "putting" distribution on the start and end of the shared/transmitted area, possibly something like that could also be done to encode different possible ancestors (haplotypes)? We would have to think about details on how to do this.