identify traits in libstd that should use multidispatch

[pnkfelix]

as a subtask of #17307, once the multi-dispatch part of associated types is implemented, we will want to update libstd to use it.

My google doc from #17826 includes a column for multidispatch; I copied the link again below.

Unsurprisingly, the vast majority of the cases I identified were in the core::ops numeric traits, though there may also be candidates in librand and maybe core::iter.

https://docs.google.com/spreadsheets/d/1Y_NAgzEK3FWcG0LjcykyKJEAibSFI3w-v-ekZ4GU8n4/edit?usp=sharing

[pnkfelix]

This is blocked by #1669, of course. (Assuming that PR actually lands, which might be more difficult given githubs new rules about merging a PR after a force-push.)

[pnkfelix]

Nominating.

On reflection, I believe part of the idea of RFC 59 is that we can safely switch from our current semantics to a multi-dispatch on input type parameters semantics in a backwards compatible fashion (since I think any code that worked before will continue to work under the new semantics ...)

... except perhaps there may be type inference issues? I am not sure about whether there are such issues, and even if they are, I am not sure whether we let type inference issues of this sort be backward compatibility blockers.

So I'm going to take a stab in the dark and nominate for P-high, not 1.0.

(N.B. It is the traits with type params that should be output associated types that are a backwards compatibility hazard; see #17826.)

[pnkfelix]

good argument was made that this is actually just a dupe of #17826 , since the categorization process will put everybody into one of two buckets.