reference and reference_omp grb::dot do not handle aliasing properly

[anyzelman]

If the two inputs are the same vector, then we should not take restricted pointers from both-- yet the reference and reference_omp implementations presently do do that.

Possibly relatedly in the context of #379 , the internal CI emits a warning that may be indirectly related:

In file included from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas/internalops.hpp:29,
                 from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas/ops.hpp:30,
                 from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas.hpp:519,
                 from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/tests/smoke/conjugate_gradient.cpp:28:
/builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas/base/internalops.hpp: In function 'grb::RC grb::internal::dot_generic(OutputType&, const grb::Vector<InputType, grb::reference, Coords>&, const grb::Vector<MaskType, grb::reference, Coords>&, const AddMonoid&, const AnyOp&, const grb::Phase&) [with unsigned int descr = 0; AddMonoid = grb::Monoid<grb::operators::add<double, double, double, grb::hyperdags>, grb::identities::zero>; AnyOp = grb::operators::conjugate_left_mul<double, double, double, grb::hyperdags>; OutputType = double; InputType1 = double; InputType2 = double; Coords = grb::internal::Coordinates<grb::reference>]':
/builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas/base/internalops.hpp:2772:60: warning: 'yy[0]' may be used uninitialized in this function [-Wmaybe-uninitialized]
 2772 |        *c = grb::utils::is_complex< IN1 >::conjugate( *a ) * *b;
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
In file included from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas/blas1.hpp:29,
                 from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas.hpp:538,
                 from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/tests/smoke/conjugate_gradient.cpp:28:
/builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas/reference/blas1.hpp:9400:27: note: 'yy[0]' was declared here
 9400 |        typename AnyOp::D2 yy[ AnyOp::blocksize ];
      |                           ^~
In file included from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas/internalops.hpp:29,
                 from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas/ops.hpp:30,
                 from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas.hpp:519,
                 from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/tests/smoke/conjugate_gradient.cpp:28:
/builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas/base/internalops.hpp:2772:60: warning: 'xx[0]' may be used uninitialized in this function [-Wmaybe-uninitialized]
 2772 |        *c = grb::utils::is_complex< IN1 >::conjugate( *a ) * *b;
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
In file included from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas/blas1.hpp:29,
                 from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas.hpp:538,
                 from /builds/zrc-von-neumann-lab/spatial-computing/graphblas/tests/smoke/conjugate_gradient.cpp:28:
/builds/zrc-von-neumann-lab/spatial-computing/graphblas/include/graphblas/reference/blas1.hpp:9399:27: note: 'xx[0]' was declared here
 9399 |        typename AnyOp::D1 xx[ AnyOp::blocksize ];
      |                           ^~

The resolution/suppression of this warning I'll leave to this issue also

[GiovaGa]

It is not clear to me what we want to do with this issue. After this issue is solved, what is the behavior we want?
Do we want:

• To assert that the inputs in the dot function are different (and so disallow this operation, by throwing an error or failed assertion), or
• To check if the inputs are the same, in which case we use a different algorithm to evaluate the dot?
  Or is this second option for a future release?