Switch code/documentation/examples/tests to the new single-arg syntax
checks if the complex conditions are overriden in set_from_related
support for prefetch from resultsource using extended_rels
adds a test with many to many and extended rels that is currently failing.
When getting a related_resultset in a row with custom rels without the extended definition, we step back, get a rs equivalent to the current row and do a search_related there.
eager check if the create_related is at all possible

When calling create_related, it should stop trying if the extended rel
does not provide the complete relationship definition.
fix the alias in the identity column

When building the identity where clause, discover the current_source_alias
to build the hash correctly
refuse to invoke create_related as class method

t/cdbi/09-has-many.t has a specific test for it.
do not use "me" on the related_resultset pessimization

This was requested by ribasushi, but it is still incomplete.
Added a TODO test with the expected final query.

Problem is: the alias is defined in $source->_resolve_join,
which is completely disconnected from the search context
so it cannot receive a different alias
Back out "support for prefetch from resultsource using extended_rels"

Blindly taking the condition retuned by an incomplete (not
all pieces of the hashref are supplied) call to the condition
maker, and attempting to order by its keys assuming it is a
hash is... naive
Untodoify tests - these are not 'nice to have', they must work
use $self->{from_bind} for extra binds transport

The __overriden_select method was used to build extra binds
that should be transported in the $self->{from_bind} array
instead.
Sanity check args passed to a coderef conditionmaker
Pass relationship name to _resolve_condition explicitly

The API is ambuguous at best, will need a cleanup some day, for now just do by
tackling even more arguments to the method, yielding insanity like:
_resolve_condition($cond, $obj, $f_rel, $f_rel) BLEH!
Fix $object->search_related aliasing, change semantics of _resolve_condition

Change the RV of _resolve_condition one last time. Now it checks the RV of the
resolved coderef (if any), and chooses (preferrably) the join-free condition
or the cross-table one. In list context returns a flag signifying if the
resulting condition is available for standalone use (false) or requires the
joins to remain (true)
Add some extra tests written while debugging, remove design draft
Rewrite the check for nontrivial joinfree conditions to throw on both new_related and set_from_related
Merge branch 'people/riba/extrels' into 0.08200_track_do_not_rebase
update Schema::Loader docs
remove mention of name_sep from Schema::Loader doc