Add AbstractArray{<:AbstractTracer} methods for common LinearAlgebra functions

[adrhill]

As discussed in #108, some functions like logdet require control flow, which currently only works with local tracers:

julia> using SparseConnectivityTracer, SparseArrays, LinearAlgebra

julia> hessian_pattern(logdet, rand(3, 3))
ERROR: TypeError: non-boolean (SparseConnectivityTracer.HessianTracer{BitSet, Set{Tuple{Int64, Int64}}}) used in boolean context
Stacktrace:
  [1] generic_lufact!(A::Matrix{SparseConnectivityTracer.HessianTracer{BitSet, Set{…}}}, pivot::RowMaximum; check::Bool)
    @ LinearAlgebra /Applications/Julia-1.10.app/Contents/Resources/julia/share/julia/stdlib/v1.10/LinearAlgebra/src/lu.jl:152
...

This could be avoided by adding methods like LinearAlgebra.logdet(M::AbstractMatrix{<:AbstractTracer}) that return conservative estimates of the corresponding sparsity pattern.

[gdalle]

I think this is necessary, I just don't know if we should do it on a case by case basis or implement an array operator classification mirroring the scalar one

[adrhill]

It's worth emphasizing that, as mentioned in #118, this could also lead to large increases in performance.
Currently, operations like dense matrix-vector products of tracers dispatch down to scalar operations. Instead, we could be a lot smarter in the way we compute unions of index sets.