Fix annotated join with non-concrete eltype iters

[tecosaur]

As raised in JuliaLang/StyledStrings.jl#57 (comment), when the eltype of an iterator is non-concrete, _isannotated will return false. To properly check such cases, we need to see if any of the elements of the iterator are annotated.

This is a bit of an interesting case, since:

• Most of the time it shouldn't be hit, we can reasonably expect most iterables to infer as producing concrete types
• The eltype of the iterator is (generally) known at compile-time, and so in any case other than the ambiguous non-concrete one, this check remains able to be done at compile-time.

With this change, join always preserves annotations. The compromise made is that iterators with non-concrete eltypes can result in join inferring a union return type (i.e. type instability with non-concrete iterators), but that doesn't seem too bad to me (I don't see how we could be completely type stable without concrete types here).

Before

After

I'd be keen to hear people's thoughts here.

[tecosaur]

The CI failures seems to come from something with Sockets on the windows CI agents, and what appears to be an unrelated failure on test x86_64-linux-gnuassertrr-net (I see poptask in the logs, and nothing string related).

[adienes]

iiuc, the tradeoff is

• now there is a type instability, possibly hurting performance if a concrete type is not inferred
• before there was a semantic ambiguity, possibly changing behavior if a concrete type is not inferred

if that's the case, I would much prefer to risk performance than to risk behavior

[tecosaur]

@adienes Yep. This results in a Union when a concrete eltype can't be inferred, but I expect any performance-sensitive applications of join likely have concrete eltypes already, and otherwise can just wrap the result in String(...) or AnnotatedString(...) to be type stable again.

We could maybe avoid more non-concrete eltypes with @default_eltype instead of eltype? That could be explored in a subsequent PR though.

[KristofferC]

Considering #55279, this should probably not be backported?

[tecosaur]

Mmm, it would be worth doing if #55279 is resolved, but it doesn't look like that's going to be easy/quick (to me at least).