right now the correlator is implemented as an 'experimental extension'
where the functionality is provided by leveraging the infrastructure
provided by the rtbf. In most cases the correlator operates similar to
the `BEAM_OP_RAW` mode of the beamformer with the exception of the
output size and the inputs to a call to `cublasCgemmbatched()`.

`init_correlator()` is functionally similar to `init_beamformer` except
only relevant to `BEAM_OP_CORR` where the cublas context is constructed
to prepare the data dimensions for the call to `correlate()`.

The `run_correlator()` function is very similar also to
`run_beamformer()` and looks again like when running `BEAM_OP_RAW`
because it matches the requirements of copy onto device -> transpose ->
matrix kernel (correlation instead of beamform) -> copy off teh device.
The copy of device is conditional however. `run_correlator()` could
really be operated inside `run_beamformer()` but to not take a penalty
in a hit on the if statment that is not needed in the beamformer
(because a copy off is always required) it would be better for now to
just have a seperate method.

The `corr_demo.c` is also functionally modeled the same as `rtbf_demo.c`
except to just demonstrate the functions of correlation and conditionaly
integration dumps.