Should exception types have a field typed by String instead of AbstractString

[timholy]

Many of our exception types have a field that is typed ::AbstractString. Should we change that to ::String? There are pros and cons:

• pro: we'd be less vulnerable to invalidation. This would fix ~280 invalidations that stem from loading packages like InlineStrings.jl, which has ~500 direct+indirect dependencies (including CSV) and so is widely used.
• con: we'd get an error-while-throwing-an-error (bad news) for any AbstractString type that has a broken convert(String, str) method.

[vtjnash]

The potential cost would be breaking where we try to use something like LazyString instead, for efficiency, forcing more work into the callers of throw.

[timholy]

If it's just that type, we could make it Union{String,LazyString}. Your point is more general than that, but it remains true that sometimes you can "close" the allowed types with relatively little cost.

[timholy]

This may not be necessary with appropriate convert methods (#44500) and callsite changes like JuliaIO/Tar.jl#136. The fundamental point is that if you know a particular dispatch will eventually convert to a specific type or set of types, then you might as well save some specialization and do that conversion eagerly.