Deprecate Cursorless snippet format in favour of community snippets

[pokey]

• [ ] #2354
• [ ] #2355
• [ ] #2356
• [ ] #2357
• [ ] Think about "snip" / "snippet" spoken forms
• [ ] Pokey migrates to community snippets

[jaresty]

What do you think about having the migrate command optionally migrate to the directory specified as the user's snippets directory? (In case folks want to keep snippets outside of community). Asking for others like me, since I don't need to migrate 😀

[pokey]

If you have a custom snippets directory, then yes that's where they'll end up

[jaresty]

Awesome, thank you.

[pokey]

@AndreasArvidsson reading this one again, I think this change would make the entire Snippets component that you moved to VSCodeSnippets in #2478 will just go away entirely, because Cursorless VSCode would no longer be responsible for keeping track of snippets at all, as we'd always send the body from community. Does that sound right?

So the only place we'd be using the file system would be for "snip make", but we can figure out a way to make that work. The key thing is that we will no longer need a Snippets component so we really don't care about moving it into file-system-common / upgrading it to new format / changing it to use file watcher. Did I get that right?

I guess there's the issue of Cursorless keyboard, but we could probably make that work external to the engine, the way the rest of cursorless keyboard-specific stuff is done in vscode side today

[AndreasArvidsson]

Unless we want to support named snippets for Cursorless keyboard, then yes.

That sounds correct.

[pokey]

Yeah I think if we wanted to support named snippets with keyboard we'd do it external to engine, like the rest of keyboard support

[AndreasArvidsson]

Then there is no problem :)