InsertionOrderIndex manages memory, but it didn't have an explicit move constructor or move assignment operator, causing segmentation faults and double frees.

See map.h changes to see why this makes this cleaner.

This is a very common pattern in practice -- and annoyingly difficult with STL maps.

This required some refactoring so than index.insert() could be called before the row was actually constructed, based on the search parameters.

It also required some awful hacks to support putting the creation function at the end of the argument list to findOrCreate(), with a variable-width arg list before it.

Integer division is really, really slow. The integer hash table benchmark spends most of its time in modulus operations!

This change shaves 32% off the integer hash table benchmark runtime, and 8% off the string hash table benchmark runtime.

Admittedly this is a strict simplification to the code.

VS 2017 is fine either way.

This is true even if the pointer-to-member is never actually used, but only has its type matched, which was what kj::size() was trying to do.

Oh well, define some damned constants instead.

Hash-based (unordered) and tree-based (ordered) indexing are provided.

kj::Table offers advantages over STL:
- A Table can have multiple indexes (allowing lookup by multiple keys). Different indexes can use different algorithms (e.g. hash vs. tree) and have different uniqueness constraints.
- The properties on which a Table is indexed need not be explicit fields -- they can be computed from the table's row type.
- Tables use less memory and make fewer allocations than STL, because rows are stored in a contiguous array.
- The hash indexing implementation uses linear probing rather than chaining, which again means far fewer allocations and more cache-friendliness.
- The tree indexing implementation uses B-trees optimized for cache line size, whereas STL uses cache-unfriendly and allocation-heavy red-black binary trees. (However, STL trees are overall more cache-friendly; see below.)
- Most of the b-tree implementation is not templated. This reduces code bloat, at the cost of some performance due to virtual calls.

On an ad hoc benchmark on large tables, the hash index implementation appears to outperform libc++'s `std::unordered_set` by ~60%. However, libc++'s `std::set` still outperforms the B-tree index by ~70%. It looks like the B-tree implementation suffers in part from the fact that keys are not stored inline in the tree nodes, forcing extra memory indirections. This is a price we pay for lower memory usage overall, and the ability to have multiple indexes on one table. The b-tree implementation also suffers somewhat from not being 100% templates, compared to STL, but I think this is a reasonable trade-off. The most performance-critical use cases will use hash indexes anyway.