Build System Update

This PR updates the build system to use PEP 621
and store project metadata in pyproject.toml instead of setup.py.

Changes include:

• Update to PEP 621 project metadata in pyproject.toml
• Remove support for Python 3.9 and earlier, and Numpy < v2.0.
• Update installation logic in setup.py to improve reliability
• Update test logic to remove pkg_resources dependency and redundant test
  directory
• Update documentation to reflect changes and add intersphinx links
• Add GitHub Actions workflow for testing the build system and development code

Description

The project metadata and packaging have not been updated for many years.
The goal of this PR is to modernize the build system and prepare for future
enhancements, such as adding more SuiteSparse module interfaces. It does not
change the existing API or functionality of scikit-sparse. This PR
updates the packaging and installation to have a unified source of metadata in
pyproject.toml, in preparation for the addition of more SuiteSparse module
interfaces like AMD, COLAMD, etc.

The pyproject.toml file now contains all necessary metadata, including project
name, version, description, authors, license, dependencies, and build system
requirements.

Version Bump

The major breaking change is the removal of support for Python 3.9 and earlier,
as well as Numpy < v2.0. As noted in changes.rst, Python 3.9 will reach its
end of life in October 2025. Numpy will end support for all v1.x versions by
September 2025. SciPy v1.14 (released June 2024) will be supported until the end
of 2026. This change ensures that scikit-sparse remains compatible with the
latest versions of Python and Numpy, without creating undue burden on us as
maintainers to stay compatible with older versions.

I have bumped the version to 0.5.0 to reflect these changes. The version
is now solely managed in pyproject.toml. sksparse/__init__.py has been
updated to read the version from pyproject.toml instead of hardcoding it.

Installation Changes

There is no user-visible change to the installation process, but the underlying
logic has been updated to improve reliability and flexibility.

The installation logic remains in setup.py, but is now restructured to ensure
user setting of SUITESPARSE_INCLUDE_DIR and SUITESPARSE_LIBRARY_DIR
overrides any other installation location. Previously, these environment
variables were placed at the end of the include list, leading to potential
issues when users had multiple installation locations for SuiteSparse.

setup.py will now automatically detect the SuiteSparse library and compile the
necessary Cython code. It will check for the SuiteSparse library in the
following order:

1. The environment variables SUITESPARSE_INCLUDE_DIR and
   SUITESPARSE_LIB_DIR (if set, these will override the default search
   paths)
2. Your active conda environment path
3. Your homebrew paths (e.g. /opt/homebrew/include/suitesparse)
4. Typical system paths (e.g. /usr/include/suitesparse on Linux, or
   /usr/local/include/suitesparse on macOS)

This information is reflected in changes to the README.md and overview.rst
files.

Test Changes

There is one minor change to test_cholmod.py. The mm_matrix function
previously used pkg_resources to load a matrix from a file, requiring the test
data to be copied into the package directory. Since pkg_resources is outdated
and not recommended for new code, the function now directly uses the path of the
test file, which is more straightforward and avoids the need for copying test
data into the package directory. This PR removes the redundant sksparse/tests
directory. All test files are now located in tests/.

Documentation Changes

Copyright information has been updated to reflect the new year and contributors.
Existing files retain the full license information and author list, but new
files should only include the copyright notice and a reference to the full
license information in LICENSE.txt, as well as the author list in
pyproject.toml.

Switch to Ruff from Black

Both the numpy and scipy projects use ruff for linting and formatting instead of black. This PR updates pyproject.toml with... roughly the same ruff settings as used in those projects. The CI workflow currently does not run linting/formatting, because there are a number of changes that would be made to existing code to update to at least Python v3.10. I will submit a separate PR with these style updates.

CI Workflows

This PR reorganizes the GitHub Actions workflows into 3 parts:

1. former ci_test.yml -> deploy.yml
2. ci-dev.yml: Install the development version, run pytest and build the docs.
3. build-test.yml: Build the distribution wheel and sdist, check both for file contents, and install/test.

The deploy.yml file has minor updates to reflect the changes to the build system, but is otherwise unchanged.
ci-dev.yml is trigged on pull requests, or manually. Contributors can change this to run on pushes to their local fork feature branches, as necessary. build-test.yml is triggered on pushes to the build-system branch, or manually.

Additional Comments

I have another PR in the works that will add an interface for AMD, and plans to
include COLAMD, CAMD, and CCOLAMD interfaces in the near future.

Looking forward to your feedback and suggestions on this PR!