fix(join): error in more places on colliding column names

[NickCrews]

I'm adding this PR mostly as a demo of what I think might be undesirable behavior. Should this instead error, because the two input columns are getting mapped to the same output column?

@cpcloud curious what you think here

[cpcloud]

Yep, this isn't entirely correct.

The name is only allowed to be merged into a single output column in the case of inner joins (with equality predicates only, which is implicit in this test).

[NickCrews]

OK, I found the fix.

In general, I think it is very fragile and bad to need to explicitly wrap every single public method of Table with the finished() decorator in the Join class. It also is some spooky-action-at-a-distance behavior here, where things will only blow up at some later function call, not close to where the source of the problem is. This is different from the rest of ibis, which usually tries to error as early/close to the original cause/function call as possible. I would much prefer it if we forced the user, at the time they call .join() to tell us how to resolve these collisions. But this is almost definitely a breaking API change, and not in scope for this PR. But just writing it down somewhere as I'm thinking of it.

[cpcloud]

In general, I think it is very fragile and bad to need to explicitly wrap every single public method of Table with the finished() decorator in the Join class. It also is some spooky-action-at-a-distance behavior here, where things will only blow up at some later function call, not close to where the source of the problem is

This is the trade-off with the redesign of the join implementation. There was no obvious alternative that ALSO allowed users to refer to more than just the immediate child table.

This convenience was something that was requested over and over again by a variety of users, and @kszucs came up with a design to support it.

This is different from the rest of ibis, which usually tries to error as early/close to the original cause/function call as possible.

Yes, again, by design.

I would much prefer it if we forced the user, at the time they call .join() to tell us how to resolve these collisions.

We used to have this behavior, and people really disliked it. It doesn't really make sense to relitigate this.

[kszucs]

We could automatically add the methods/properties after the class definition to make it more future-proof to the ir.Table changes.