Improve the "monomorphization backtrace" for const-eval errors

When a const fails to evaluate, if there are generics involved it can be crucial to know where and how the const got instantiated to understand the error. For this purpose interpret::ErrorHandled has the emit_note function that marks the point in the code where an erroneous constant is encountered.

However, this could be done better:

• For promoteds and inline consts, the const is defined right where it is used, so the extra note makes little sense and should probably be suppressed.
• The monomorphization collector prints similar errors related to instantiation of generic functions as "the above error was encountered while instantiating this function". It plays some tricks with the error count to ensure this is only emitted right after an actual error. We could do something similar. That would lead to less duplication of "erroneous constant used here" messages, but it means if the first evaluation of a constant is without a decent span, we'll never get the note. That may be an okay trade-off? Currently GVN evaluates constants without a decent span, but maybe that should just be fixed. (It's not trivial since GVN has its own representation for consts that doesn't hold the span -- and probably it shouldn't hold a span, probably the error should be emitted before turning a const operand into that representation.)

Fixing this will require refactoring a bit how this note is emitted; currently emit_note has no idea which constant it is that failed and it can't compare old and new error counts to determine if the error would be right "above".

Start by tracing interpret::ErrorHandled::emit_note and the monomorphization collector's related instantiation diagnostics. Inspect how GVN represents constants and handles spans. Done means const-eval diagnostics avoid redundant notes for promoteds and inline consts while preserving useful monomorphization context.