Entirely and utterly rewrite populate(), fixing the variable hash issue

Yes, it took ~3 years to properly fix it. The changeset size alone should make
it pretty clear why this happened, but this is not the entire story.

At first the bug was deemed fixed back in a9bac98f. Due to miscommunication
and lack of tests this issue did not come up again until last winter (the devs
thought they nailed it, the users thought it's a wontfix).

Then when the actual tests got written it became clear that... words fail me.
In short - some folks had the bright idea that a fast-path insert got to be
able to understand *MULTI-CREATE* semantics. There was a great deal of tests
that did all the wrong things from a conceptual point of view but they were
passing tests nonetheless. So the thing got tabled again...

In the meantime a recent flurry of improvements to the relcond resolver
took place, mainly centered around fixing the custom relconds call modes.
A side effect was uncovering that populate() is invoking relationship cond
resolution in an... insane for the lack of a better word way. Some shims
were put in place and the only remaining bit were warnings, however with the
improvements available it in fact possible to cleanly implement
"subquery-based multicreate".

So instead of punting - the entire codeflow of populate was reworked with the
new toys in mind. The data mangler _normalize_populate_args is gone for good
(no more mindless copy of passed in data). The amount of fallbacks to create()
is reduced and each instance now properly warns of the problem. All in all
this is another one of "if something changed - I fucked up" changes.

As an added benefit - we now have a foothold into validating subquery-based
multicreate implementations - soon (one would hope) the code will migrate
to wider use within ::ResultSet.

A notable part of this commit is the *undocumented* implementing part of the
Swindon consensus - the is_depends_on flag is now added to all belongs_to
relationship attrs. The actual implementation of the rest is subject to
another battle.

Now on to 0.082800
Now that populate is rewritten: finalize the resolver fatal sanity checks
Change once more the signature of the custom cond coderef (augment a446d7f8)

Since there hasn't yet been a stable release with the new naming, and given
I've already mistyped the long-form twice, might as well rename things and
stay consistent.
Document and add example of foreign_related_object
Correct test of ${^WARNING_BITS} - as haarg++ noted: runtime != compile time

Also bump Moo prereq for proper
 * presence of undefer_all
 * fixes of meory leaks in Sub::Quote/Sub::Defer
Bundle trial SQLA for the trial of DBIC (reuse dq technique f4a8b21e)

Supersedes 609fa215, to be reverted before 0.082800
The current_source_alias is prepended, not a literal "me."
Add 3rd example of col info in ResultSource->add_column

Rather than just say "it's a hashref", provide a simple example of what that
hashref might look like.