Add extension ZIP cache directories to type roots and implement standalone extensions sharing types

[lyonsil]

As an extension developer, I want to be able to reference types from other extensions when I'm writing code that depends on those extensions.

Extension ZIP files are decompressed by the extension service so they can be loaded and executed at runtime. We would also like to use those decompressed d.ts files inside of VS Code when developing other extensions so we can use their types.

Platform.Bible conditionally unzips extensions into paranext-core\dev-appdata\cache\extensions. Let's leverage this.

1. Let's add paranext-core\dev-appdata\cache\extensions to typeRoots
2. We may need to make it so directory extensions' .d.ts files are copied into the extension cache in order to gather extension types from directories. However, that will probably mean the currently in development extension will have its .d.ts file twice, which could pose issues. Probably the solution at least for now is to make a short documentation about how to add other extensions' directories to your typeRoots
3. We may need to make it so if an extension is provided via a folder, the unzipped folder in the cache is deleted/not created. That way, if someone has a production version of an extension but is also developing the extension, they won't get duplicate types
4. Document this functionality where zipped extensions can be shared based on their .d.ts files put in the cache and note that it may be worth deleting this folder if you experience unexpected types issues.

[tjcouch-sil]

We should also think of a way to better support sharing types between extensions you're developing. Getting types from the cache would allow development off of other published extensions, but we don't have a clear way of doing that with in-development extensions right now. We might just have to teach people how to point typeRoots to the appropriate directory...

Maybe we could add another cache directory that copies the .d.ts files for directory extensions every time the extension host starts (or reloads). Then the .d.ts files that are read could be at least almost up-to-date. I don't know if TypeScript will be ok with duplicate definitions of your types, though. I guess you could remove src/types, but that would break development without Platform.Bible open.

For an extension you're working on that already has a published version installed, Maybe we could detect when an extension is provided by a directory (instead of a zip) and delete the unzipped files in the cache.

[tjcouch-sil]

PRs:
Added app://cache/extension-types for extension type sharing by tjcouch-sil · Pull Request #659 · paranext/paranext-core
Added cache/extension-types to typeRoots for easy sharing extension types by tjcouch-sil · Pull Request #52 · paranext/paranext-extension-template
Added cache/extension-types to typeRoots for easy sharing extension types by tjcouch-sil · Pull Request #10 · paranext/paranext-extension-template-hello-world
Added cache/extension-types to typeRoots for easy sharing extension types by tjcouch-sil · Pull Request #26 · paranext/paranext-extension-text-collection
Added cache/extension-types to typeRoots for easy sharing extension types by tjcouch-sil · Pull Request #12 · paranext/paranext-extension-word-list

Documentation update comparison:
https://github.com/paranext/paranext-extension-template/wiki/Extension-Anatomy/_compare/f236273423c8b5b11a99f1bc71523997abfa5b74...034bea77f62284ea6b9102e2735240e71f0c24a1

[tjcouch-sil]

Turns out that typeRoots takes the first module definition it finds and ignores subsequent ones in order of its entries. Amazing! This means we can order typeRoots appropriately with the cache at the very end and other things before it and not have to worry about deleting cached stuff and whatnot.

Unfortunately, I discovered a few problems with the proposed solution in the issue description along the way, so I had to change things a bit:

• Using the existing cache/extensions folder doesn't work because TypeScript considers the folder name to be the module name, and all those folder names have a version number on them. Generally, the folder name for the extension doesn't technically have to match the extension name anyway. So I ended up making a cache/extension-types folder that contains folders that contain the types files.
  • Each folder in cache/extension-types is named the name of the extension's TypeScript module (which should match the extension's name and optionally have a suffix - see below). Inside that folder is the extension's .d.ts folder renamed to index.d.ts because this is the only file structure that TypeScript liked. Other methods like just copying the .d.ts files into the cache/extension-types folder caused the modules to be lazy loaded into IntelliSense, so papi-shared-types shared interfaces weren't seeing the extensions' contributions unless the extension's types were imported.
• I decided that, for consistency's sake, I'd assume the extension name is the module name in the extension's .d.ts file. I also assumed the extension's .d.ts file would be named <extension_name>.d.ts, <extension_name><other-stuff>.d.ts, or index.d.ts. Otherwise, the extension developer can add a types field to the manifest.json to indicate where the types file is.