BUG FIX: Variable overwrite in PTSwap for-loop

[astrolamb]

Describe the bug
Parallel tempering swap overwrites data when completing a swap. This leads to neighbouring swapped chains to have the same likelihood and parameter values.

Issue
The buggy code in the for-loop under Line 682

Imagine the following scenario where p0s=[0,1] and swap_map = [1, 0] (ignore log_Ls for this example). swap_map is a map to assign the new positions of the elements of p0s. In this example, swap_map should swap the positions of the elements p0s such that p0s==[1,0]. This doesn't happen in this code.

In the first iteration of the loop (j=0) over the elements of both arrays (size=2), we have the following assignment: p0s[0] = p0s[swap_map[0]]. The value of swap_map[0]=1, therefore p0s[0] is assigned p0s[1]=1.

Therefore, after one iteration of the loop, the elements of p0s is [1,1].

Continuing through the second iteration, swap_map assigned the first element of the current p0s (which is 1) to its zeroth position.

Hence, the loop returns p0s=[1,1], not p0s=[1,0] as desired.

The bug is that the arrays p0s and log_Ls are being overwritten with every iteration of the loop, and its elements are being accessed with the expectation that it is not being overwritten.

** Test **
Here is a plot of the distribution of log-likelihood (from the T=1.0 "cold" chain) for a single-chain MCMC, and 4-temperature PTMCMC for the buggy and fixed code. The MCMC is fitting a multi-dimensional Gaussian distribution to noisy data generated from a multi-dimensional Gaussian distribution. The distribution of the log-likelihoods should be consistent between the cold-chain of the PTMCMC and the single-chain MCMC. As you can see, the buggy code explores a less-likely region of the parameter space. The corrected code (in this PR) is consistent with expected behaviour.

[vhaasteren]

This looks completely fine. Clean changes