RFC Supporting `scipy.sparse.sparray`

### Context

SciPy is now favoring sparse arrays (i.e. `scipy.sparse.sparray` and its subclasses) over sparse matrices (i.e. `scipy.sparse.spmatrix` and its subclasses) to enlarge the scope of matrices to $n$-dimensional data-structures since SciPy 1.8 (see https://github.com/scipy/scipy/pull/14822).

Sparse matrices now subclass their associated sparse arrays (see https://github.com/scipy/scipy/pull/18440).

scikit-learn has been supporting sparse matrices but now also needs to support SciPy sparse arrays.

### Proposed solutions

Ordered by preference:
 - Use `scipy.sparse.issparse` and the `format` attribute everywhere and not use `isinstance` at all
 - Use `isinstance` on private compatibility class defined to be `scipy.sparse.spmatrix` or `scipy.sparse.sparray` conditionally on SciPy's version (i.e. use `scipy.sparse.sparray` if available)
 - Rely on duck-typing or the class name to check for sparse arrays

cc @ivirshup

COMMENT:
I found this issue and want to either inject some new questions into these comments, or I will open a new issue if people prefer that. I will follow this big-arc strategy post with a specific post asking about return values for features that return sparse.

**SciPy current state and plans for sparse**
SciPy now has a document [SciPy migration from spmatrix to sparray](https://docs.scipy.org/doc/scipy/reference/sparse.migration_to_sparray.html) and I am working to help implement that process for scikit-learn. The conversion to sparray within SciPy has been completed. The documentation has been warning new code creators to use sparray for a few releases now. We are now in a phase of waiting a release or two before officially deprecating spmatrix (by that I mean making deprecation warnings appear). The final timing has not been universally agreed on and part of that depends on adoption rates among heavy users like `sklearn`. I am dedicating time toward this goal. Hopefully it is helpful for `sklearn` too. As of v1.15 SciPy sparse has very rudimentary nD sparray support, and I expect it to grow quickly. Broadcasting is another feature that sparray will be developing soon. These are good features for which conversion to sparray will be necessary.

**Conversion steps:** (tracker)
1. [x] (PR #27090) **test both sparray and spmatrix**. This requires accepting sparray inputs and spmatrix inputs equally
2. [x] (PR #30858) **convert all internal code so it works with either sparray or spmatrix** This differs from 1. in that spmatrices created inside `sklearn` do not get tested in 1. This changes the syntax of manipulations of internally created `spmatrix` to work for `sparray` or `spmatrix`. It does not change outputs.
3. [ ]  (PR coming) **determine whether to return spmatrix to sparray** We all agree that if there is a sparse input the sparse output should use the same type as the sparse input. But functions that don't have sparse input yet return sparse output will need to have a way to choose the type of the output. (discussed somewhat above). 
        - Some libraries (like pyamg) are making a hard cut at a specific version, (advantage: one change for users). Users only need to wrap the output e.g. `sp.csr_matrix(...)` if they want spmatrix.  
        - Some libraries are adding kwargs to indicate the return type (two user changes -- first when kwarg is introduced or default value is changed -- second when kwarg is deprecated eventually).  
        - Some libraries create two function names: one for sparrays and one for spmatrices (one change if the sparray name is the long term better name, two changes if the sparray func name will be changed to a canonical name later).
5. [ ]  (PR coming) **ensure index arrays are 32bit for codepaths that use 32bit libraries** sparrays set index dtype by type of input instead of values of input (spmatrix use values). This is a tricky part of the conversion so I thought it might help to separate it from larger more straight forward changes.
6. [ ]  (PR coming) **change internal usage from spmatrix to sparray** (this should be a long straightfoward PR with only the name change and no other logic/code.
Feedback on this process is welcome. If this is better in a new Issue please let me know.

Labels: New Feature, API, Needs Decision, RFC