Suggestion: Split dictionary and core

[jirisykora83]

I try SymSpell and it looks great. But one thinks I notice almost intermediately it bring dictionary file in my project (even if I do not use it). I understand it helps with a quick start but I strongly believe in real application most of the users make own. But even if not. I think it will be better to have NuGet package split to SymSpell.Core and SymSpell.Dic.En for example. For keeping compatibility SymSpell could be composed of these two packages (something like Microsoft.AspNetCore.App.

[KOLANICH]

I have created an abstraction layer for several libraries doing word splitting for Python. All of the libs receive kind of word list. Some ship the wordlist with them, some (like this ones) don't. I think that having an own word list for each library is redundancy and a violation of DRY principle (it may be convenient for the devs not to depend on compatibility though, but it is still harmful).

I think we need a common spec for the dictionary files, because quite some software use them. So these wordlists could be installed and updated separately. So I won't have to bother "this lib requires a wordlist", "this lib bundles an own one".

I also wonder if there are any benchmark datasets for such a task. I mean not only speed benchmark, but one of quality of splitting. And maybe even classifying the errors the implementations cannot avoid.