Having these within the internal context rtbf context seemed to add an
extra layer of abstraction that was unnecessary in favor of readability.

Evaluating this started when the correlator was added. This was
initially to be the approach before changing the `nr_rows/cols_*` from
generic cublas input names (A,B,C) to more specific names as part of the
application.

Then with the specifc names it seemed more appropriate to remove it
altogether because it further improves readability and although it was
considered to keep the more generic interface but the
beamformer/correlator really is fixed and will not be reconfigured.
Makes more sense to keep the information close to the implementation.

A beamformer should provide a calibration function. Without it an
application using the beamformer must implement its own and is of little
use other than wanting to use predetermined weights. Considering this,
adding the correlation infrastracture (dedicated array data,
`d_cor_matrix` and others) as part of the rtbf context then makes sense.

This also caused a change to the cublas structure to remove the generic
`_A`, `_B`, and `_C` suffix naming to more specific naming for use.
Providing a dedicated pointer-to-pointer interface for the correlation
output data. Removing the need to reuse the `d_arr_C`.

Having the allocations available along side the beamformer is also
looking forward to want to provide real-time adaptive rfi cancellation.
Because, this helps set them up to run together. Otherwise, reusing a
memory region (`d_beamformed`) or the cublas context resources
(`d_arr_A/C`) requires that resources be shared and reconfigured between
the two operations.  Which would work but perhaps too complicated for
what we want to do.

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.

not completely sold on the `rtbf_plugin.h` as part of the rtbf. On one
had it makes sense because it would be an extension that rtbf provides
describing its data block size. But, on the other hand it would make
sense to keep it closer to the thread code.

update demo code for using 12 element per fid

Project uses configuration files to now send in parameters instead of
defining parameters on the command line.

Also changed to have the configure file only build if it is not a
subproject. Otherwise the superproject will make sure to get the
configuration file and set the parameters.

Note that in current meson version that without an implementation of
`get_gen_dependency_args()` the nvcc compiler does not track
dependency changes (configuration parameter changes in the headers) and
so a recompiliation results in a partial target rebuild. This requires
the project be wiped or setup for a new build every time a configuration
is changed with something like `meson --reconfigure`

number of elements was 160 when initially developing new rtbf. This was
chosen because starting rtbf happened after re-learning xgpus
limitations. A multiple of what looks like 32 is needed (although I
remember being told it was 16) before the xgpu test program resulted an
error of zero. Using 160 was the first multiple above the ALPACA spec of
138 (although it would have been nice to be multiples of 16, so 144
could be used -- but even then it may not have performed as well). But
it became clear and an oversight on my part that 160 wouldn't work because
ALPACA uses 12 f-engines and 12 doesn't divide 160. This pushed it up to
192.

The ALPACA spec is for 80 beams. Packing more than 80 beams was looked
into when on the GBT. Geometries with beam spacing up to 96 beams was
looked at.

cublas main is no longer built

reduce build shell script to adjust

add raw and beam power mode test functions

creates weights for the swept beam pattern test of array elements as if
in a ULA. Also optionally upload from a weight file.

check outputs from each mode with plotting done for raw op mode

single program to test the operational modes of the rtbf. Allows for
benchmarking calls of the rtbf in eaach mode. Previous tests had only
looked at performance of `BEAM_OP_STI`.

was only incrementing if checking the output and so outputs were
actually being placed into the same location instead of rotating through
the host memory buffer

Handling of output stokes (polarization) parameters is now a float4
vector. This is more suitable to the information it presents.

STI outputs are now ordered differently to have the stokes values
contiguous in memory grouped by beam, then frequency, then sti time
sample output.

The rtbf host output memory is now (void*) intending to indicate to the
user the output format changes based on operational mode. The internals
handle conversion and sizing. Memory lenghts are now all bytes, except
for the input/output_offset that are not sized in bytes for convenience
to the user in doing pointer arithmetic.

added a `complex16_t` to be used with rtbf for all input data. Input
sizing is now computed uniformly using this type.

Made the output buffer in the rtbf a `void*` as part of the effort to
make more consistent the types and sizes in the input output being used.
In different modes, the output right now is always an array of floats,
but between OP_STI and OP_RAW the shape of the data is different. This
is part of perhaps using a float4 vs a complex float type like cuComplex
on the output between OP_STI and OP_RAW that a user would use to parse
data on the output.

update test scripts to use new type and make more uniform

description updates to context members, with more work still to do