stack traces: only print relevant aspects of parametric types

[StefanKarpinski]

Offshoot of #45687. The idea is to limit what aspects of a type in a stack trace we print to only the parts of the type that are relevant to dispatch. This can be computed as a combination of concrete types of the arguments and the type of the method that is called. For example, if slot in a method is AbstractArray and the argument is Vector{SomeLargeType} then we could just print Vector.

The general concept is to only print as much detail about a type as is required to understand the dispatch choice. It's a bit tricky to make this precise, however. Type intersection isn't useful since the concrete argument type is always a subtype of the method parameter. If the concrete argument type is C and the parameter type is A then what we want to print is a type B such that A >: B >: C.

Slightly more generally we can say the same about A, B and C as method signature tuple types, not just individual argument slots. For example, suppose we have a method that looks like (AbstractDict{T, <:Any}, AbstractVector{T}) where T and the actual call has types (Dict{String, SomeLargeType}, Vector{String}) then we'd want to print (Dict{String}, Vector{String}). We want to include String because it's necessary for the type to be the same across the two arguments in order for the method to match; we don't need to include SomeLargeType because it's irrelevant to the method matching. So we need some kind of bounded widening of types by walking up the type lattice from a concrete point to a broader type that is still within the argument type.

[mikmoore]

Not exactly the same idea, but an (easy?) interim option might be to just report the written type signature of the relevant method (ie, the types in the method definition). Or, one step more sophisticated, to replace the written types in the signature with the concrete input types of the call to the same parameter depth as the definition.

[vtjnash]

That is a bit opposite to the intent of the code currently, which is to show the part of the stack traces that cannot be seen directly from looking at the source code. The declaration is completely uninteresting, since you can always look at the source file if you want that

[StefanKarpinski]

Idea for how to compute B from triage discussion: take B = A ∩ drop_type_params(C, d) for some d that makes the printed form of B "short enough" for a stack trace. Basically, the idea is that we can replace type parameters with <: Any past some depth; this gives us a type D that may not be a subtype of A but if we intersect D with A then we get back a type that's a subtype of A.