Hash join

Much of this has been reviewed before. If you're happy with that, you can probably concentrate on ca2c76a12e2ffdbbad1c7b8353b30c60e039a654, 0dc4503ffad805f053fe132b923e887a304c62fc and 6b64447a44e7446b4d9afcffec38b83cf2b2375f.

The last is the most substantial.

* It changes how the intermediate form of `HashTableLookup` works. Instead of having another copy of the original inner plan which got turned into the loader plan, it has just the list of tables that came from there. This is needed for the map folder to know what columns to project early. The hash table is a special conduit (worm hole?) for these.

* It changes the criteria for checking a hash join. Conceptually, if the cost model were good enough, it could always be considered. But costing it is tricky, so for now at least, it's only when the nested loops join it is presented with has no conditions between the two subsumed by the scan. In short, when an index could not be used. This leaves hash join effective when it's a big win and avoids is when it might be a small win.

* Previously, a hash join was only used when it could handle _all_ the join conditions. That is too limited. It's fine when it can handle _any_ of them. The rest will be done with `Select`.