Improve Osa implementation

[maxbachmann]

This reduces the binary size of osa_distance by more than 25% while improving the performance.

Binary size before change:

File .text   Size  Crate Name
0.0%  0.7% 1.9KiB strsim strsim::osa_distance2
0.0%  0.1%   199B strsim alloc::raw_vec::RawVec<T,A>::reserve::do_reserve_and_handle
0.0%  0.1%   140B strsim alloc::raw_vec::finish_grow
0.0%  0.0%    28B strsim core::ptr::drop_in_place<alloc::vec::Vec<usize>>
0.0%  0.0%     0B        And 0 smaller methods. Use -n N to show more.
0.1%  0.9% 2.3KiB        filtered data size, the file size is 4.4MiB

Binary size after the change:

File .text   Size  Crate Name
0.0%  0.6% 1.7KiB strsim strsim::osa_distance
0.0%  0.0%    28B strsim core::ptr::drop_in_place<alloc::vec::Vec<usize>>
0.0%  0.0%     0B        And 0 smaller methods. Use -n N to show more.
0.0%  0.7% 1.7KiB        filtered data size, the file size is 4.4MiB

The following graph shows the runtime for random strings of different lengths:

[maxbachmann]

This special case would help performance if the two strings are similar, but hurt if they are not.

Generally it would be better to reduce the common prefix + postfix and return early in case the remaining length is 0. This has the same runtime, but always either helps the performance or doesn't really hurt. In our case the added binary size isn't really worth it though.

[dguo]

I would also guess that it's rare to actually hit these cases in real world usage.

[maxbachmann]

I think we could probably get away with two vectors instead of three. However that's more work and I would need to test the effect of the additional bookkeeping on performance and binary size. For this reason I will try this separately.

[dguo]

This is awesome! Thanks for the comparison data!

[dguo]

I would also guess that it's rare to actually hit these cases in real world usage.