1406 Fix bug in ak.lookup

[reuster986]

Closes #1406

Previously, the ak.lookup() function, which treats key-value pairs as a function to be applied over args, implicitly assumed that the user-supplied keys were in the order output by ak.unique() and ak.GroupBy(). This is the most common usage, but it is not inherent to the semantics of the function, and when a user (legitimately) supplied keys that were unique but unordered, ak.lookup() would return the wrong answer.

This PR fixes that behavior by performing ak.GroupBy(keys) to ensure the anticipated ordering. Because this can be an expensive step, it also adds a keys_from_unique keyword arg as a shortcut for when keys come from unique/GroupBy.

This PR also adds a unit test for ak.lookup in the join_test.py file (because lookup is a special case of a join).

[mhmerrill]

looks ok to me.

[stress-tess]

Just a comment about more informative testing.

I checked and couldn't find anything, but I also wanted to make sure that there weren't any places where we use lookup that should be updated to set the keys_from_unique flag

[stress-tess]

I know it's not consistent across our tests but i prefer

self.assertListEqual(res.to_ndarray().tolist(), ans.tolist())

because it gives more precise information about where the lists are different

for example

>       self.assertTrue((ak.array([1,2,3]) == ak.array([1,1,3])).all())
E       AssertionError: False is not true

vs

>       self.assertListEqual(ak.array([1,2,3]).to_ndarray().tolist(), ak.array([1,1,3]).to_ndarray().tolist())
E       AssertionError: Lists differ: [1, 2, 3] != [1, 1, 3]
E       
E       First differing element 1:
E       2
E       1
E       
E       - [1, 2, 3]
E       ?     ^
E       
E       + [1, 1, 3]
E       ?     ^