Improve singlet gate

[ramhiser]

1. The singletGate has obvious computational bottlenecks. The matrix x of observations is coerced to a data.frame not once but twice: here and here. After these are fixed, the code needs to be profiled.
2. Steve DeRosa noted that the singlet gate based on prediction bands is often too narrow, thereby excluding cells above the bands. By default, we use the prediction bands corresponding to the 99th percentile. Either we should use another approach, such as LOESS, or we should have an argument to include the cells above the bands using the convex hull after outliers have been removed.
3. Steve also pointed out that the singlet gate sometimes leans to the right. That is, the slope of the regression fit is rotated in a clockwise manner from the apparent slope in the plots. This is related to point 2 above -- if we stay with rlm, the robustness arguments need to be investigated.

[ramhiser]

Here are singlet gates for six HVTN065 samples. Specifically, samples 296012.fcs and 296014.fcs exhibit the slant mentioned in point 2 above.

Apparently, the slant is due to excessive debris. Steve mentioned that the ordering of the upstream gates is not immutable and that a debris gate will likely reduce/remove the slant and improve model fit.

Also, beneath the gate in sample 255239.fcs, there is a small cluster of cells that is shaded light blue here. Steve mentioned that this is an artifact and is possibly related to time. His lab now generally gates out the first 10 seconds of a sample because there are often measurement fluctuations, i.e., a burn-in period. Steve recommended that we plot Time versus IFNg, look for this burn-in effect, and then gate out the first 10 seconds.