Add generic create_spoken_forms function

[pokey]

Let's create one version of create_spoken_forms that can be used in many places. This would be a function that you can pass in a string, and it returns a list of possible ways to speak the given string. I think @rexroni's speakify is a great place to start. Here are a few things I can think of to support off the top of my head:

• [x] numbers decomposed into single digits
• [x] for numbers in the range 1900–2100, support "nineteen eighty five", "two thousand five", and "twenty nineteen"
• [x] pull abbreviations from abbreviate.py. That should prob use the new csv stuff fwiw
• [x] file extensions, which should maybe also be a list and use csv support. I made an initial pass at making them a list fwiw
• [x] split camel / snake into words
• [x] support saying subsequences of the given phrase rather than the whole thing
• [x] symbols, ideally pulling from your symbol map in keys.py, which could prob use a csv re-work as well, though I think that's prob going to cause a merge conflict for every single knausj user 😅
• [ ] do we want the prefix fanciness?
• [ ] potentially need to toy with some of this type of replacement, though maybe let's start without it and see how necessary it is with something like conformer

The places I can think of offhand to use this function are:

• [x] focusing an application
• [x] launching an application
• [x] file manager files and folders
• [x] #387
• [ ] @Gauteab's tree-sitter identifiers in https://github.com/Gauteab/talon-tree-sitter-service
• [ ] I could use them for tags and lists in my things3 grammar

In terms of naming, I've seen the following names:

• create_spoken_forms
• create_spoken_form
• make_speakable
• speakify

I think I'd vote for create_spoken_forms but they all seem fine to me

[knausj85]

One small note from #399: it'd be nice to preserve Dragon's number parsing for those that might stick with it.

[knausj85]

From testing around this, these are my thoughts:

• I don't see an immediate need for the prefix fanciness(?), but I do think we should generate the variants with and without symbols provided it's not too expensive. Mostly to disambiguate some sloppy folder names I've run into heh

some-file -> some file, some dash file

• I would probably vote in favor of generating the variants with all specified spoken forms of a symbol/digit, but maybe that's a bad idea in practice? we might want some form of "preferred spoken form" thing otherwise

I've got an initial pass of this working with the filemanager etc in my personal branch that I can merge into the revelant PR eventually. Generally, this is working very well save for the few known issues.