user would set the rtbf context to a weight array and then call update
weights. This was removed.

Also, initialization of the beamformer would return the device weight
memory in an indetermined state. The init now initializes the weights to
all ones [CMPLXF(1.0, 0)] and then the user is to make a call to
`update_weights` to change them. This allows the beamformer to at least
not be completely broken initially.

The update mechanics now have `update_weights` accepting an array of
float values to load to the device. The idea is that the user
creates some weights and manually update them and then they are to still
be responsible to free that memory.

simplified and improved the logic in `update_weight` to combine the
conjugate transpose into one loop instead of across multiple temporary
arrays. Two versions are left here and will follow up with a new commit
that removes the second (because I think I personally favor the first
implementation as it is more descriptive in its memory access).

this allows for the GPU to have DMA access to host memory directly

use of `compiletime_info` struct in the library. Fix static mallocs that
were larger than default stack parameters for large block testing.

cleanup `cublas_beamformer.h` definitions

compile parameter names have changed to be more descriptive. still
working on some of the size parameters. Working on a struct containing
the compiled info.

started working on registering host memory, stopped to get parameters
changed and to have compiled info to compute sizes.

this has the start of detecting if pinned memory regions overlap that
seems to happen for small beamform sizes

mwr probably had it there because he might of thought it was needed to
make the data float*. But, really the memory can be reinterpreted.

functionality to update beamformer weights are what is left in
`update_weights`. The ability to update from a file is still needed but
should be provided as a way to populate memory and then call
`update_weights`

currently a call to init beamformer, with the `weights_h` set, without a
call to `update_weights` will lead to bogus results that would be hard
to identify. Need a way to safely know weights have been applied (or
not).

setup of the pointer and data flow is part of internal context
initialization

remove the intermediate variables and use setup from internal context to
control data flow.

There might be a way to use function pointers to select a
post-processing task. Looking into it there is a cuda example from the
cuda samples in section 6 called "function pointers"

removed non-descriptive names of variables in favor of those that were
descriptive that were just temporary movement variables

not necessary, in fact probably will get rid of them, just being
consistent for now.

different control flow for operation of rtbf. not sure if best way at
the moment. Because in reality BEAM_RAW_OP doesn't need to be checked
instead just dump the output.

still more to do. already know need to remove the iq kernel but this is
just a small incremental change.

Not sure why that implementation was still in the beamformer.

That version assumes data as received at the network (group by f-engine
packetized). The cublasGemmBatched works on batching frequency bins and
uses that as the slowest moving dimension. It is still useful code for
elsewhere in the system and was copied out in a temporary file to be
moved somewhere else more permanent (not yet decided). But I could not
figure out why it would have been kept around. The thought came to me
for looking at beamform spectra data but, still needs to be beamformed
first needing to be grouped by batch for this implementation.

(just a thought, would need to think about it)
transposing the data in that specific way may not be necessary as
long as the data is contiguous the pointer-to-pointer interface just
needs to point to the start of each batch (frequency bin) and as long as
the data is contiguous there

looking over transpose code since still probably faster to transpose in
GPU than CPU and will continue to do that.

But, because input assumes network ordered data means that xgpu needs to
have a transpose in it. The real goal would be to get to a gpu pipeline
implementation that gets data on device and just pass that between
kernel methods.

also, these transpose could probably be sped up with a LUT

gemmBatched uses a pointer-to-pointer interface where the input arrays
to gemmBatched is an array of the memory addresses for the start of each
back. The `d_arr_*` array's are these interface array's. They were being
malloc'd with a size equal to what the data sizes are where these arrays
just contain the start of the next batch. The array size only needs to
be the batchCount.

internal context to have device pointers

move gpu block dimension magic numbers to rtbf context

header downsizes for a smaller example and beamformer adjusts magic
numbers for setting up dimensions to support that.

init method setups up the weights instead of only being loaded by a
file, this makes `cublas_main` unusable but this is for setting up to
verify output and be able to start making adjustments

`testbeam` was meant to be `multibeam`. the new testbench sets up data
using the time dimension as scanning angle to plot beam patterns. So
each time element is an angle. beamformer weights are ULA and the angles
chosen split up the number of beams. All the same data is in each
channel

couldn't compile for cuda 11 using complex, needed to move to cuComplex

change formatting of code

start to adjust header definition for alpaca but ended up more with
todo's and notes to try and understand what to do in moving from flag to
onr to alpaca and be more flexible/standalone

flag beamformer library has always been part of a larger project, this
strips that down to a separate repo and removing much of the other
baggage

additionally, a lot of changes have been made to adjust flag to onr but
we need now need the beamformer to look more like flag and there was no
tag or real commit to revert back