Implement fuzzy finder as default filter for Select/MultiSelect

[mikaelmello]

Is your feature request related to a problem? Please describe.

Fuzzy finder is very valuable, and I don't think it'd imply in a significant performance cost at runtime.

[Baarsgaard]

Hi, I'm taking a stab at this as I really want to make use of it.

I'm running into some decisions I would like your input on.
In order to support a fuzzy filter, it's necessary to sort the list of options.

I could implement a separate function like Filter<'a, &T> which takes the list of options and replaces self.options with the return value.
The issue with this approach would be when and how to handle filter vs the new ranking/matcher function.
Should the list of options be both filtered and ranked or should filter and ranking/matching be mutually exclusive.
If both should apply, which order, filter first?

Alternatively, I would suggest changing the Filter<'a, &T> function signature from:

pub type Filter<'a, T> = &'a dyn Fn(&str, &T, &str, usize) -> bool;

And give full access to the entire list of options

pub type Filter<'a, T> = &'a dyn Fn(&str, &'a Vec<&T>) -> Vec<&'a T>;

// Alternatively mut ref
pub type Filter<'a, T> = &'a dyn Fn(&str, &'a mut Vec<&T>);

This would allow users to implement whatever filter/ordering logic they want, as well as allowing the use of a default fuzzy filter.

Lastly, it would be simple to add a feature flag enabling the fuzzy vs contains default filter that is currently in place allowing users to exclude the fuzzy_matcher library.
Or implement it using a different library if they feel like it.

[Baarsgaard]

Since #176 is merged, could this be closed?

[mikaelmello]

Yes, thanks! I'll work over wrapping-up everything that's been merged into a release