Include ambiguous signatures when computing guard signatures
After fixing #30118, the behavior of #31649 changed. Instead of crashing
immediately upon attempting to print `spvec`, the first time would fail
with the correct ambiguity. However, any subsequent attempts to print
the same value would yet again result in a crash. Upon investigation,
the series of events leading to this crash are as follows:
1. Showing the first error message attempts to put `convert(::Type{Any}, ::Nothing)` into
the cache (matching the previous `convert(::Type{Any}, x::Any)` method).
2. jl_compilation_sig widens this to `convert(::DataType, x::Any)`. No guard signatures are allocated,
because `ml_matches` does not return `convert(::Any, ::sparse_t)` because it is uncallable due to
the ambiguity.
3. Upon the next call, we find `convert(::DataType, x::Any)` in the cache and use it. The subsequent
successful return conflicts with type inference's result that this call will not return (i.e. is
inferred to Union{}).
To fix this change the `ml_matches` call in step 2 to include ambiguous matches, thus allocating
guard entries for these signatures and preventing the cache match. That works for this issue, but
I should note that I have seen additional crashes along similar lines while working on this fix,
so there may be additional issues in the vicinity.
Fixes #31649
