Bug 5048: ResolvedPeers.cc:35: "found != paths_.end()" assertion (#680)

Bug 5048: ResolvedPeers.cc:35: "found != paths_.end()" assertion (#680)

This bug was caused by a4d576d. ResolvedPeers::retryPath() used
connection object pointers to find the original path location under the
incorrect assumption that the Connection pointers never change. That
assumption was wrong for persistent connections: ResolvedPeers stores a
half-baked Connection object rather than the corresponding open
Connection object that the unfortunate caller got from fwdPconnPool and
passed to ResolvedPeers::retryPath().

While working on a fix, we discovered a second reason why the pointer
comparison was a bad idea (and why a simpler fix of comparing addresses
rather than pointers was also a bad idea): The peer selection code
promises to deliver unique destinations, but we now suspect that, under
presumably rare circumstances, it may deliver duplicates. This broken
promise is now an out-of-scope XXX in PeerSelector::addSelection().

Squid now eliminates the search (and the previously documented concern
about its slow speed) by remembering Connection's position in the
destination array. The position is remembered in a smart Connection
pointer (compatible with Comm::ConnectionPointer) so that the rest of
the code (that does not really care about all this) is preserved largely
unchanged. Most changes are just renaming the pointer type.

Also freshened a FwdState call and comment made stale by 25b0ce4.

Also marked an out-of-scope problem in maybeGivePrimeItsChance() caller.