Fix potentially ambiguous .as_ref()

[robjtede]

#1017 was reported as a breaking change made to rustls. This isn't really the case. The true culprit is this vague .as_ref() call.

In general, it is allowed to change a fn that used to take T to now take impl Trait where T: Trait. AsRef is an unfortunate example of a trait that is often misused like this.

There may be more of these cases, if possible they should be switched so that a new AsRef impl or change such as was made in rustls doesn't break downstreams again.

[Jarema]

Hey!

Thanks for the PR!
As I agree with the general approach to what is breaking and what is not, I think it's a little different story with such an important and impactful library as rustls, where breaking should probably be considered anything that is actually breaking anything, with plethora of use cases and different API usageges. Of course, the situation was handled nicely and swiftly by rustls team.

To the point of PR:
Indeed, such as_ref() can be unfortunate and lead to ambiguity. We will definitely scan for any other similar occurrences.

Once again, thanks for the contribution.
LGTM!