Add RandomTrajectory Sampler

[joshspeagle]

This is typically referred to "Galilean Monte Carlo (GMC)" (see, e.g., this). The basic idea is to initialize a particle with some velocity v and launch it in a random direction. It then proceeds unimpeded until it reflects off the likelihood boundary set by L_j > L_i, computed using the normal vector at that location. If the reflected particle is itself still outside the boundary, we reverse our trajectory. This procedure is analogous to Hamiltonian Monte Carlo (HMC) methods, except that our potential function is a uniform well with infinitely steep boundaries rather than a smooth log-posterior.

While the name makes sense (I believe it's a derivative of "Hamiltonian"), I find the whole MCMC analogues (and renaming) to be more confusing that enlightening at this point, especially concerning the underlying dynamics. For instance, the "MCMC"-like procedure employed to choose new live points is really a bounded random walk, so why not just call it a random walk? Likewise, Galilean MC is just a bounded random trajectory bouncing off surfaces, so why not just call it a random trajectory?

Notes:

• I also think "GMC" is subject to the same optimization opportunities as HMC via, e.g., NUTS, in order to adaptively set step sizes and integration lengths while still satisfying detailed balance.
• Calculating the normal vector at the bounding surface is a pain, and generally requires the gradient of the log-likelihood or some approximation to it. Computing this properly actually matters, since an improper reflection would result in non-uniform sampling. Maybe see this link?
• This might be equivalent to reflective slice sampling.

[joshspeagle]

Linked wrong issue in the commit. I actually resolved #14.

[joshspeagle]

This has now been removed as of 1757c8e45b17dd5061a7f583024bd051b86c0901.

[joshspeagle]

I'm returning to this to see if I can get this implemented properly. I've thought a little bit more about how to get this to give numerically stable results and how to properly tune some of the parameters involved and think I might have a shot at getting this to work now.

[joshspeagle]

Looks like I thought wrong. Results were somewhat closer this time around (as in I got something working) but performance was still sub-optimal and required too much hand-tuning.

[joshspeagle]

I found this neat paper outlining how to actually do this properly using "Hamiltonian Slice Sampling". So I'm re-opening this since I think I can actually get that version implemented fingers crossed.