This was an embarrassing close call - entirely redo custom set_from_related

This was an embarrassing close call - entirely redo custom set_from_related

I am flailing at this point - unacceptable. TL;DR: 03f6d1f7 is wrong, 1adbd3fc
is wrong, so is 5592d63 and most importantly 350e8d57 is unacceptably wrong.

The entire "I will inflate a bag of data into a synthetic object" was wrong
from the very beginning (03f6d1f7) but I was too busy keeping the tets passing
to realize what crack-mountain I was standing on.

The crux of the issue is: it didn't occur to me that forward-resolution
(related_resultset) *always* starts from an object by definition, while
reverse-resolution (set_from_related) takes either an object or a bag of
values or undef. Moreover: in the custom coderef the user does not care at
all about the type - all they want is to get their values. In light of this
self_result_object is actually a mistake - we should have simply provided
self_values from the start, but that ship has already sailed. On the other
hand the reverse-resolution bag is a new feature, and we can simply (and
correctly) settle on passing in a hashref of values: foreign_values

This fully avoids the "how do I get an object out of plain data" problem
and nicely settles all the outsanding (untested until now) problems.

I just wish I would have seen this a week earlier... sigh. At least not
shipping this live is a consolation...