Implement efficient tree filtering for multiple constraints

[abensonca]

When using the filtering approach to generating constrained merger trees, the process will become extremely inefficient (i.e. almost all trees will be rejected) as the number of constraints grows. Find ways to improve the efficiency.

[abensonca]

For example, a case where we want to condition a MW tree to have both an LMC and an SMC. The probability of both will be very small. But, an approach something like this might work:

1. Build the tree as normal, but using a mergerTreeBuildController that prevents following any branch that falls below $M_\mathrm{LMC}$. Note, the resolution of the tree would still be much smaller than $M_\mathrm{LMC}$ - so we would get branching events to halos with $M < M_\mathrm{LMC}$ - but we just wouldn't follow them. This leaves us with an incompletely-built tree, but sufficient to judge whether the tree has an LMC.
2. Apply a filter to select if an LMC is present. If one is, proceed, otherwise, start over from step 1.
3. Now continue the build of the tree, but this time with a mergerTreeBuildController that prevents following any branch that falls below $M_\mathrm{SMC}$. If we require the SMC to merge with the LMC branch, this build could additionally be restricted to only build the LMC branch.
4. Apply a filter to select if an SMC is present.
5. If an SMC is present, accept it and continue. If no SMC is present, we have two options:
   a. Discard the tree and return to step 1;
   b. Restore the tree to the state corresponding to step 2 (i.e. just an LMC present), and go back to step 3. (See note below on how to handle the statistics of this.)
6. Build the remainder of the tree down to the mass resolution.

In this way we build only just as much of the tree as needed before applying our filters. This should be much faster as it allows us to rapidly reject unacceptable trees.

Note on statistics: If we do step 5b then we have to be careful about the statistics. By repeatedly growing parts of the tree until we get an SMC match we are biasing the results (potentially). Suppose we allow a range of LMC masses. Higher mass LMCs might be more likely to have an SMC than lower mass LMCs. But, in 5b we just keep growing branches until we get an SMC - so every mass LMC is equally likely to get an SMC. To account for this we would need to weight each tree by $1/N_\mathrm{SMC}$ where $N_\mathrm{SMC}$ is the number of trials it took to get an SMC. This gives us a Monte Carlo estimate of the probability of a given LMC having an SMC.

[abensonca]

This would need some new mergerTreeBuildControllers (to do the partial tree builds), and some modification of the mergerTreeBuilderCole2000 class to allow it to resume build of a incomplete tree.

[abensonca]

We would also need a mergerTreeBuilderCompositorclass, which takes two mergerTreeBuilder objects, A and B, calls the build() method of A and then, if the result is not null, pass the result to the build() method of B, and then return the result.

[abensonca]

Also, in the mergerTreeController class we can stop building a branch when it drops below $M_\mathrm{LMC}$ or if it reaches a redshift $z > z_\mathrm{LMC}$. Which should make the tree build even faster.