Incremental matching

[saghen]

In the typical case, users type one character at a time, so the previous needle ends up being a prefix of the new needle. In this case, rather than calculating the scoring matrix for the entire needle x haystack, we can calculate it only for the new characters in the needle. If a user has typed 8 characters and types a 9th, this would lead to a theoretical 8x speedup.

We should also look at the implementation from nucleo to see what kind of interface we should expose

Related alexpasmantier/television#19

[saghen]

Initial support merged in #24 but need to investigate the performance and ideally add prefiltering + exact match bonuses

[saghen]

Frizbee seems to be so fast that the increased match size due to storing the score matrx for incremental matching drastically outweigh the benefit of not reprocessing parts of the score matrix. The best approach I found while testing in #52 was to store the indices of the matches and only process those haystacks on additional chars. This only led to a significant speed-up with high selectivity (<20% matching).

I'd like to revisit this in the future since #52 made solutions much easier, since we process items sequentially and individually, rather than in buckets in groups of $LANES