More robust array overloads

[adrhill]

The current array overloads based on element types of AbstractArrays can cause method ambiguities in downstream applications, see #227.

An MWE of a workaround using CassetteOverlay.jl has been proposed in #227 (comment).

[adrhill]

Continuing the discussion from #277, where @gdalle said:

The problem, as always, is parametric types. We can define \(::AbstractMatrix{<:Tracer}, ::AbstractVector{<:Tracer}) but the dispatch for any concrete matrix type will take precedence. The same goes for the wrappers at fault here, namely Lower/UpperTriangular and friends.

Finding a work-around for this is the exact purpose of this issue.
Using method overloads on \ as an example, we could

1. loop over types like LowerTriangular (and UpperTriangular, etc.)
2. within the loop, overload on respective owned types like LowerTriangular{Dual}
3. have these overloads split the LowerTriangular{Dual} into primals and duals and let LinearAlgebra handle the rest.

[gdalle]

LowerTriangular{Dual} is not a concrete type, LowerTriangular is itself a wrapper around any abstract array, eg sparse or GPU work too. Same for Symmetric and friends

[adrhill]

Oh dear, that does not help. 😬