WIP: leakage-aware GST

[rileyjmurray]

(I said I'd close this PR due to awful commit history. But then everything fixed itself when I changed the target branch from master to develop. So I'm keeping open.)

[rileyjmurray]

Text from an email Piper sent (not showing plots since they contained real data):

I was looking at the model violation tab, trying to work out why the smaller L models weren’t fitting the data as well as might be expected as quantified by Nsigma. I think this maybe be a function of how we calculate Nsigma = (2delta logl -k)/sqrt(2k). The number of non-gauge model parameters N_p is reported as 351 in the leakage-enhanced GST report (I don’t have any particular sense of whether this is correct). The number of data points N_s is 193 for L=1. This means that k (the degrees of freedom) is negative if you just calculate it as N_s-N_p. In cases like this, pyGSTi chooses k=1. k remains small until L is fairly large, which means two delta logl must be quite small for Nsigma to be small. This explains why we don’t see any red boxes in the per sequence detail for the L=1 iteration (and Nsigma is large enough that I would expect to see some or at least more dark gray squares than can be seen).

If you directly compare two delta logl between the two fits, you can see that the two delta logl is in fact smaller in the leakage-enhanced report than in the standard report.

I think the solution here is just to make sure that the first iteration of leakage-aware GST uses L=2 instead of L=1. (Or, more generally, we use the smallest L where N_s > N_p.)