refactor build script and integrate pfb/correlator

See merge request !1

Remove the `is_subproject` check in the meson build file. This would
conditionally create and handle config data generation and info based on
use as a subproject or not. This seemed to be a very poor and
non-standard approach using config data. Now, the parent project using
the library will pass parameters as part of `default_options` to the
subproject . Then the project always dumps its own config file rather
than being passed up and created by the parent project. This was also
modified and is reflected in the other xb-engine core libraries.

still want to work and look into if this is the best way to architecture
all the components if a plugin approach is chosen.

sync the defaults for number of time samples between With the rtbf and
pfb when building. The fft size must be a factor of the time per block
for the PFB. It is not required that RTBF_NTIME be the same PFB_NTIME.
Just that the individual checks are satisfied. However, when compiling
the library it makes more sense that this might be the common use case.

pgplot has been a dependency for a long time, but have alaways wanted to
ultimately make that optional. This starts that.

the `demo*` codes that do the benchmarking rely on some XB engine
parameter info. Primarily because for ALPACA benchmarking use some data
assumptions to show meaningful results when plotting. But, also because
the library incorporates the network data reorder and the
Fengine/Xengine structures is where that is derived from.

this should help allow for unifying all the demo codes

pfb context needs to have a meaningful initialized value if the pfb is
not going to always be initialized so that when cleanup comes the code
doesn't have to also check operational mode to clean up

The rtbf is generally flexible to having the pfb integrated but it
undermines much of the way it was implemented (e.g., the way the post
beamform kernel was setup and switching `d_output` between
`d_beamformed` and `d_post_beamform`). However, this should still work.

The thinking is that for right now it is more important to show that the
PFB can work with the beamformer and to have a base benchmark on
profiling. I do not exactly need it in hashpipe yet. In the current
form this would work except the way the rtbf builds the pfb uses a
subproject and it is not allowed to have subprojects that have
subprojects and so for this to work with the xb-engine/pipeline the use
of the pfb in the rtbf this way would need to be able to access the pfb
as a subproject of xb-engine that lives next to rtbf (the other
subproject of the xb-engine)

But getting back to the idea; implement now beamformer+pfb to benchmark,
go work on other things outside the context of the rtbf. Then one that
is all demonstrated come back to looking how to integrate these two
components with the possibility of improving the architecture for a more
generalized function chaining for how a pipeline would work.

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.