struct Concrete(u32);

  impl Concrete {
      fn m(self: &Box<Self>) -> &u32 {
          &self.0
      }
  }

resulted in a confusing error.

  impl Concrete {
      fn n(self: &Box<&Self>) -> &u32 {
          &self.0
      }
  }

resulted in no error or warning, despite apparent ambiguity over the elided
lifetime.

This commit changes two aspects of the behavior.

Previously, when examining the self type, we considered lifetimes only if they
were immediately adjacent to Self. We now consider lifetimes anywhere in the
self type.

Secondly, if more than one lifetime is discovered in the self type, we
disregard it as a possible lifetime elision candidate.

This is a compatibility break, and in fact has required some changes to tests
which assumed the earlier behavior.

Fixes rust-lang#117715

This makes a small change as requested in code review, such that if there's
ambiguity in the self lifetime, we avoid lifetime elision entirely instead of
considering using lifetimes from any of the other parameters.

For example,

impl Something {
  fn method(self: &Box<&Self>, something_else: &u32) -> &u32 { ... }
}

in standard Rust would have assumed the return lifetime was that of &Self;
with this PR prior to this commit would have chosen the lifetime of
'something_else', and after this commit would give an error message explaining
that the lifetime is ambiguous.

This test reproduces a rustc ICE. Unfortunately, the changes to lifetime
elision mask the original ICE bug by making this function signature
illegal. However, by simplifying the signature we can regain the
original ICE.

I think that this test is supposed to be a treereduced version of
122903-1.rs, but is actually identical.

Change the algorithm which determines whether a self lifetime can be
used for return type lifetime elision, such that we consider lifetimes
attached to any reference in the self type, so long as Self can be found
anywhere inside the type of that reference.