Per-programming-language dictionaries

Some terms are very common even in comments for some languages, but not used in others. Or sometimes one particular spelling/capitalization/hyphenation variant is preferred over what an English dictionary might prefer.

In addition to the user dictionary, per-file dictionary, and per-workspace dictionary, multiple per-language dictionaries can be added.

Please suggest good locations where these dictionaries should be installed. My preference is that they be plain one-word-per-line text files with no need for comments or any other kind of formatting.

I envisage the files as not intended to be edited manually by the user or via the editor or LSP or plugin etc in which Harper is being used. (But you would actually be able to edit them anyway.) The official way would be to file an issue or PR for any words to be added.

Like the other ancillary dictionaries they wouldn't support verb or plural inflection like in `dictionary.dict` - just put each actually used form on its own line.

Ideally Harper knows which file format or programming language the file is in, which it already determines when opening the file based on the file extension.

Otherwise the per-language-dictionary would have to duplicate the mapping of many file extensions to one filetype - look how many Markdown files have - which would not be DRY. Maybe harper already stores this info?

These dictionaries should've be large encompassing every type of API call but should include ones that are the most "wordlike" and which frequently appear in code comments. Such as `vec` or `hashmap` or `HashMap` etc.

Begin with Harper’s existing user, per-file, and per-workspace dictionary handling and its file-extension language detection. Compare how dictionary.dict handles inflection, then define installation locations and the language-to-dictionary mapping. Done means language-specific one-word-per-line dictionaries are selected without duplicating extension mappings.

Written by the indexing model from the issue text.