RadixNode and stringIn are a bit slow

[johnynek]

We have a benchmark for stringIn, which exercises stringIn. I also compared it to a naive iteration through a list to check if we beat that, and we don't.

I think there are a few issues:

1. we use binary search to find if a character is in a list, if there are only a few possible strings, the cost of the binary search might be comparable to checking the few strings. An alternative would be to use an indexing scheme so we can compute the index into an array from the char value.
2. stringIn knows the full strings that can match, but it discards them, so it has to allocate at the end again. If we built the tree storing the fully matching value so we don't need to reallocate a string copy we will get a significant win. When I benchmark stringIn(s).void in our current benchmark it almost matches the naive loop above (it should beat it), but without the void it is about 2x slower.

approach should be to move all the code to matching the RadixNode into that file (we are splitting the code now and some of it lives in Parser). Then we should scalatest very completely that matching code. Finally we should add a benchmark that compares stringIn when there are a much longer list of strings over a longer input that will match. The current benchmark is pretty hostile since the naive thing is very close to optimal.

Finally, with that in place, we should experiment with the two suggestions above to see if they can actually solve the problem.