Add `read_matrix`

[BenBrock]

Remove the grb::matrix constructor that takes a std::string, replacing it with a new function read_matrix that accepts a std::string containing a file path and returns a grb::matrix.

[BenBrock]

We discussed this in our GraphBLAS C++ API meeting today, reaching a consensus that this is the correct design we want for reading matrices in.

One major point of discussion was the fact that we do not do any type erasure---that is, users must explicitly define what type they want to use in the matrix they read the file into.

// I must know that "my_file.mtx" contains `float` elements.
auto x = grb::read_matrix<float>("my_file.mtx");

In order to support different types at runtime, users would need a type erasure mechanism such as a std::variant. (A std::variant is an object that can contain one object of a collection of types, where the specific type is determined at runtime.)

Users would first need to inspect the file type to see what type it contains, then use an if statement to handle each type separately on different code paths.

// What we'd have to do to dynamically handle types

auto matrix_type = grb::inspect_matrix_file("my_file.mtx");

std::variant<grb::matrix<float>, grb::matrix<int64_t>> x;

if (matrix_type == GrB_FLOAT) {
  x = grb::read_matrix<float>("my_file.mtx");

  // Do something with x
} else if (matrix_type == GrB_INT64) {
  x = grb::read_matrix<int64_t>("my_file.mtx");

  // Do something with x
}

// x contains either a `grb::matrix<float>` or `grb::matrix<int64_t>`

We could potential introduce a grb::matrix_variant type that erases some or all of the grb::matrix template parameters. It would dispatch at runtime to the correct implementation for each algorithm.

[DrTimothyAldenDavis]

You might see a similar issue come up with deserializing a matrix from the output of the C++ equivalent of GrB_Matrix_serialize.