Rebase Oracle datetime inflation test on top of DBICTest::Schema::Event

The butchering of Track made sense in 2007, not so much today

The test seems to behave identically, hope I didn't fuck up anything...
https://travis-ci.org/dbsrgits/dbix-class/builds/30513847#L398
Avoid ResultSourceProxy calls whenever possible

Along with efficiency gains this commit makes a very subtle but crucially
important change: From here now on when we operate on an instance, we are
guaranteed to query this instance's result source. The previous codepaths
would nearly randomly switch between the current rsrc instance and the one
registered with the corresponding result class.

This will allow for proper synthetic result instance construction further on
Re-fix relcond resolver: revert 5592d633 (in turn partial revert of 03f6d1f7)

I had the right hunch during 03f6d1f7 but could not substantiate it: the
issue is that the custom coderef expects objects or nothing. Yet here and
there internals pass around bare hashes of data (or sometimes even undef).

Asking users to complicate their coderefs further is just not an option -
it is mindbending enough as it is. So the only way to go forward is indeed
to create "synthetic result objects" and pass them down the stack. This time
however there is a twist - after the overhaul in 4006691d we now *can*
indeed construct such objects on top of the bare DBIx::Class::Core - in
other words mission fucking accomplished.

This commit *may* need to be reverted in case it turns out that 4006691d is
a no-go (check the test change to t/inflate/datetime_oracle.t in 12b348d9
for an example of what was taken for granted wrt direct $class-> calls)
If this is the case - not all is lost. We should be able to use a hidden
class with an actual source instance that we would ammend on the fly... But
let's hope we will never get to this bridge :(