Sampler interface refactoring

[jared321]

The sampler interface is presently implemented as a class and sampler executions require that calling code provide

• the log of the joint posterior density function and
• a draw_func.

Note that the sampler class does not hold state and should, therefore, likely be implemented as a sample function that returns its results.

Looking forward to integrating bilby samplers (Issue #124), we see that bilby samplers work with

• the log of the joint prior density function and
• the log of the likelihood

with the log of the joint posterior density function ostensibly being assembled by these by the samplers.

My current understanding is that bilby users typically do not provide the joint priors, but rather specify the log of the marginal prior densities with the understanding that the parameters are independent or they can provide joint priors in the form of multivariate normals.

Therefore, the sampler interface should be updated by

• switching from a sampler class to a _create_sampler function in the package's private interface that returns a sample function,
• switching the sample function's interface to require
  • the log of the joint prior density,
  • the log of the likelihood, and
  • draw_func (done in accord with Issue draw_func refactoring #156)
• adding the package's private interface a construct_log_joint_posterior function that samplers can use to build the density function from given arguments

As part of this, consider having the constructed log of the joint posterior set into the sampler results and in the calibrator's results.

The expectation is that this refactoring should not change results in any way if the same problem is run before and after using the same random seed.