Clearer name of method/variables before refactoring
Pass the main rsrc in attrs, instead of trying to fish it out later
Teach order_by stability analyzer about search_related

There is more stuff we can do here as noted in the FIXME added to the very
end of _extract_colinfo_of_stable_main_source_order_by_portion. But for the
time being this will do (also see the subsequent tests for extra insanity we
could and should add)

Tests come in the next commit
Original (now passing) tests prompting the order_by analyzer revamp d3fcb2d74
Revert optimistic and sloppy changes from 3705e3b2 - DBI does not always DTRT

In addition I rebroke the issue from RT#79576, ffs man pay attention

<ribasushi> general question - does DBI guarantee that objects with stringification overload will get their stringification called
<ribasushi> or is this up to the DBD (and thus will vary)
<mje> ribasushi, I had an issue in DBD::ODBC ages ago with this - looking for it now
<mje>  rt 78838 - bind_param does not correctly stringify blessed objects when connected to MS SQL Server, magic was not being applied in DBD::ODBC case
<mje> so I think the answer to your question is DBI does not but DBDs should if they are written correctly
<ribasushi> I wonder why DBI does not
<timbunce_> ribasushi: no explicit ‘guarantee’ but I think any place it doesn’t is probably a bug.
<ribasushi> timbunce_: given mje had to do magic in his DBD, I suspect DBI has a "hole" somewhere then no?
<ribasushi> basically I was looking into removing the explicit stringifications in DBIC, hence the question
<ribasushi> if there is consensus that DBI ought to do it all on its own, we could test for it, fix it up, and then I disable the checks when I detect a sufficiently advanced DBI.pm
<timbunce> yes, ribasushi: “… we could test for it, fix it up, and then I disable the checks when I detect a sufficiently advanced DBI.pm or something”
<timbunce> :)
<ribasushi> nod ;)