[RFC] Use binary search for all lookups

[wingo]

@alexandergall has been seeing problems due to the branchiness of the linear probe for ctable lookups. This branch attempts to see if using the generated binary search helpers instead of linear probe in Lua fixes this problem.

I suspect it doesn't fix the problem, as this snabbmark shows:

$ sudo ./snabb snabbmark ctable
No PMU available: single core cpu affinity required
hugetlb mmap failed (Cannot allocate memory), falling back.
insertion (40% occupancy): 116.82 ns per iteration (result: nil)
lookup_ptr (40% occupancy): 212.69 ns per iteration (result: cdata<struct 1461 *>: 0x7fd9e98e4ae0)
lookup_and_copy (40% occupancy): 184.19 ns per iteration (result: cdata<struct 1461>: 0x41219360)
streaming lookup, stride=1: 118.02 ns per iteration (result: -2000001)
streaming lookup, stride=2: 78.21 ns per iteration (result: -2000001)
streaming lookup, stride=4: 84.25 ns per iteration (result: -2000001)
streaming lookup, stride=8: 78.65 ns per iteration (result: -2000001)
streaming lookup, stride=16: 68.07 ns per iteration (result: -2000001)
streaming lookup, stride=32: 65.50 ns per iteration (result: -2000001)
streaming lookup, stride=64: 67.30 ns per iteration (result: -2000001)
streaming lookup, stride=128: 63.73 ns per iteration (result: -2000001)
streaming lookup, stride=256: 64.70 ns per iteration (result: -2000001)

Compare to the results before (see the lookup_ptr case):

$ sudo ./snabb snabbmark ctable
No PMU available: single core cpu affinity required
hugetlb mmap failed (Cannot allocate memory), falling back.
insertion (40% occupancy): 116.32 ns per iteration (result: nil)
lookup_ptr (40% occupancy): 149.35 ns per iteration (result: cdata<struct 1461 *>: 0x7f8ff9241040)
lookup_and_copy (40% occupancy): 107.87 ns per iteration (result: cdata<struct 1461>: 0x425bc660)
streaming lookup, stride=1: 126.87 ns per iteration (result: -2000001)
streaming lookup, stride=2: 116.42 ns per iteration (result: -2000001)
streaming lookup, stride=4: 100.83 ns per iteration (result: -2000001)
streaming lookup, stride=8: 91.41 ns per iteration (result: -2000001)
streaming lookup, stride=16: 83.98 ns per iteration (result: -2000001)
streaming lookup, stride=32: 81.41 ns per iteration (result: -2000001)
streaming lookup, stride=64: 78.14 ns per iteration (result: -2000001)
streaming lookup, stride=128: 79.53 ns per iteration (result: -2000001)
streaming lookup, stride=256: 77.88 ns per iteration (result: -2000001)

But, who knows!