- Try to speed up SVT_SparseArray transposition by implementing a one-pass
  approach that uses ExtendableJaggedArray intermediate buffers (offss, valss).
  See src/readSparseCSV.c where this approach is already used.
  Note that this will require that ExtendableJaggedArray structs are able
  to support other types of columns (only support int at the moment).

- Implement C_subassign_SVT_with_Rarray() and C_subassign_SVT_with_SVT().

- Speed up row selection: x[row_idx, ]

- Implement more matrixStats methods for SVT_SparseMatrix objects. Those
  that are still missing and are actually used in Bioconductor are:
  rowMeans2, rowSums2, rowRanks, rowQuantiles, rowMads, rowIQRs, rowAlls,
  rowCumsums, rowWeightedMeans, rowAnyNAs) + corresponding col* methods.

- Add unit tests for Compare methods for SVT_SparseArray objects.

- Implement Logic methods for SVT_SparseArray objects.

- Implement Math2 methods and **some** Math methods (only those that
  preserve sparsity that is: abs, sign, sqrt, ceiling, floor, trunc, log1p,
  asin, asinh, atan, atanh, expm1, sin, sinh, sinpi, tan, tanh, and tanpi).

- Implement more summarization methods for SVT_SparseArray objects.
  See R/SparseArray-summarization.R

- Implement aperm() method for SVT_SparseArray objects.

- Implement readMatrixMarket() to read a Matrix Market file as a SparseMatrix
  object, and writeMatrixMarket() to write a SparseMatrix object to a Matrix
  Market file. These will be the analogs of readMM() and writeMM() from the
  Matrix package.
  See https://math.nist.gov/MatrixMarket/formats.html

- Implement table() method for SVT_SparseArray objects of type logical,
  integer, or raw (should it go in R/SparseArray-summarization.R?)

- Add unit tests for the SVT_SparseArray stuff.

- Implement function for loading a TENxMatrixSeed subset as an
  SVT_SparseMatrix. Test it on the 1.3 Million Brain Cell Dataset.

- Go after dgCMatrix objects in ExperimentHub (query(eh, "dgCMatrix")),
  convert them to SVT_SparseMatrix objects and try to do the things that
  are usually done on them.

- Convert 8322787x1098 dgTMatrix (ExperimentHub resource EH5453) to
  SVT_SparseMatrix and try to do the things that the curatedMetagenomicData
  folks usually do on it.

- Do we need a dedicated container for SVT_SparseArray objects of type
  logical with no NAs? There's only one possible nonzero value for these
  objects (TRUE) so there's no need to store the nonzero values. More
  precisely, the dedicated container could use the following simpler internal
  representation: keep the tree structure of SVT_SparseArray objects but
  instead of using a list of 2 parallel vectors for each non-NULL leaf (this
  list stores the offset/value pairs), use an integer vector to only store
  the offsets.
  The dedicated container would be called OVT_SparseArray, for "Offset Vector
  Tree". It would be another SparseArray subclass. Would inherit the "dim"
  and "dimnames" slots from SparseArray and only add the "SVT" slot ("type"
  slot not needed).
  This would make the memory footprint of an OVT_SparseArray object half
  that of an SVT_SparseArray of type logical!
  Notes:
    - The type of an OVT_SparseArray object would always be "logical".
    - 2 typical use cases for OVT_SparseArray: (1) represent the result of
      calling is.na() on an SVT_SparseArray object, (2) represent the
      adjacency matrix of a graph.
    - OVT_SparseArray is to SVT_SparseArray what ngCMatrix is to dgCMatrix.
    - Coercion from SVT_SparseArray to OVT_SparseArray should be supported.
      Would replace all sparse vectors in the tree with offset vectors, by
      stripping off the "vals" component from the non-NULL leaves.
    - Coercion back from OVT_SparseArray to SVT_SparseArray should also be
      supported. Would produce a SVT_SparseArray of type logical.
    - Like with a logical SVT_SparseArray (and, conceptually, with any
      array-like object of type "logical"), we should be able to use an
      OVT_SparseArray object to subset another array-like object of identical
      dimensions (conformable arrays).
  ALTERNATE APPROACHES:
  - Make OVT_SparseArray an extension of SVT_SparseArray.
  - Or simply don't introduce a new class for this and make it an internal
    business of the SVT_SparseArray representation to use either a Sparse
    Vector Tree for the general case or an Offset Vector Tree for the
    special "type=logical with no NAs" case.
