The `issymmetric` check tracks an `offset` that it uses to go from (row,
col) to (col, row). However, currently this doesn't account for the fact
that if a column is empty, entries in `colptr` will be identical. E.g.,
in #605, we have
```julia
julia> S = sparse([2, 3, 1], [1, 1, 3], [1, 1, 1], 3, 3)
3×3 SparseMatrixCSC{Int64, Int64} with 3 stored entries:
 ⋅  ⋅  1
 1  ⋅  ⋅
 1  ⋅  ⋅

julia> SparseArrays.getcolptr(S)
4-element Vector{Int64}:
 1
 3
 3
 4
```
The offset `3` corresponds to rows in the third column, as the second
column is empty. This PR checks for empty columns, in which case we may
exit the call immediately.

Fixes #605

The purpose of this PR is to not call `==` directly, and use `_iszero`
instead. This is to help integration with
[IntervalArithmetic.jl](https://github.com/JuliaIntervals/IntervalArithmetic.jl)
since `==` for our `Interval` type does not always return a Boolean.

Closes #609.

I did not change two checks using `===` since this would break the
behaviour for `-0.0`.

This improves performance:
```julia
julia> using LinearAlgebra, SparseArrays

julia> D = Diagonal(rand(3000));

julia> S = sprand(size(D,1), 0.01);

julia> @Btime ldiv!($D, $S);
  30.053 μs (0 allocations: 0 bytes) # master
  1.585 μs (0 allocations: 0 bytes) # PR
```

These methods do not require the `eltype`s to match exactly, and should
work as long as the values may be stored in the destination.

This prevents us from being influenced by things like `LD_LIBRARY_PATH`,
and ensures that we always load the correct `libsuitesparseconfig` that
came with our JLL.

I find it worth pointing out explicitly in the docs that LDLt, which
mathematically looks like a drop-in replacement for Cholesky that does
away with the positive definiteness requirement, comes with the
following caveats:

* It fails for a lot of matrices (for example,
`ldlt(Symmetric(sprandn(1000, 1000, p)))` basically never succeeds for
any relevant sparsity `p`) due to the requirement that all leading
principal minors be well-conditioned
* In CHOLMOD, `ldlt` is significantly slower than `cholesky` as it does
not have a supernodal implementation

So I made some docstring edits to clarify the relationship and tradeoffs
between `cholesky` and `ldlt`.

Citation for these claims: pages 106-107 in the CHOLMOD user guide at
https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/v7.10.3/CHOLMOD/Doc/CHOLMOD_UserGuide.pdf

(cherry picked from commit 75eaa18, PR #625)

Run CI with Julia 1.12 on the release-1.12 branch and backport #625.

(cherry picked from commit 70921fb, PR #617)