Decide on generic-ness of functions like Iterator::try_find and array::try_map

[scottmcm]

array::try_map tracking issue: #79711
Iterator::try_find tracking issue: #63178

try_map only allows the closure to return a Result, and has the function also return a Result.
try_find was added in #63177 allowing the closure to return any Try (v1), but the function itself always returned a Result.

With Try v2, there's no longer an associated type for the Error type, so try_find needs a different approach. #84767 changed it to a bit of a hacky version that's probably not what should be stabilized. And whatever solution is picked should probably be used for try_map as well.

I think there are two main options:

1. Support only Result. This is certainly the easiest option. It's unclear how important supporting other types would be -- this might depend on the error handling WG's work. If it ends up having a not-really-Result type that's used in some situations, this might be suboptimal.
2. Treat residuals as a "family", and offer a trait that can be used to get the correct output type. There's a sketch of how this could look in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-try_find, with a prototype implementation in scottmcm@0b12d0d#diff-c552b2bf18fb3212fe93dd601ce487badf5e50faf9aeed4db7b0f6c22571ef01R2442 This is more complicated and may need an RFC, but is also the most general, with additional benefits elsewhere.
3. Make the return type of the methods generic, so they're picked by the context of the caller. While this would work, I think the annotation burden would be frustrating -- .try_find(...)? wouldn't work, as ? isn't a strong enough context to force any particular family of types.

[scottmcm]

With #91286, this is now resolved using approach 2, via a Residual trait.