Provide table join method - #903

Oops, I ended up rewriting all this from scratch. There are just a few lines of remnant code from recfunctions.join_by().

Given that we now have the astropy.units framework, should there be at least a warning if columns with unequal units are merged ?
In simple operations add, multiply etc. the units checking is very strict, so as a user I could naively expect that values are transformed automatically if I join to tables that have fluxes as e.g. ergs/s and W/s.
I don't think that needs to be implemented right now, but I would like some warning output that is it not (as that's easy to overlook in the documentation).

Putting warnings here for inconsistent values is a good idea. Will do.

Minor point, but could we instead backport collections.Counter in the compat module and just use that instead? I realize this is a trivial thing but if/when we ever drop 2.6 support we can immediately drop that too--this is preemptive code rot protection :) I'll do that if you think it makes sense to.

I actually looked at collections.Counter. It does a whole lot of stuff I never realized beyond just counting, and the class is actually pretty involved at first glance. In the end I decided porting wasn't worth the time to save 4 lines of trivial code. Even if it just works out of the box, you have to port the tests, and so on. If you want to do the port, go for it, but my feeling is that we (you) have higher priorities.

Otherwise it might be worth putting this little counter function in utils as a super-lightweight counter.

This might not be the best way to go about creating the "out" dict. Some dict subclasses don't have non-empty constructors--the most common that comes to mind would be collections.defaultdict. If left is a defaultdict, if the expectation of this function is that a new defaultdict is returned there would probably also be an expectation that it have the same default_factory.

Instead why not just out = deepcopy(left)? This should preserve any invariants of the original object but still deep-copy all the values (and the keys for that matter, I think).

Good point. I don't remember if there was a reason I didn't use deepcopy but this seems like a cleaner approach now.

I kind of just want to write this as

try:
    return left.__class__(itertools.chain(left, right))
except TypeError:
    raise MergeConflictError()

I played with this a little bit. I like the idea, but I think it also opens up opportunity for unexpected results. For instance if left='abc' and right='cde' then the above succeeds and returns '<itertools.chain object at 0x5f5ed10>'.

We'll need to come back to merging meta for more realistic use cases, but for now I'll leave the strict but predictable version in place.