Implement subpath pattern exporting for papi-components

[rolfheij-sil]

Our custom components, located in lib/papi-components/src are exported from a single index.ts file.
A cleaner solution would be to create a separate export file for each component.

More info can be found in the Node JS docs

Additional reads:
https://github.com/audi2014/react-async-concurrent/blob/main/docs/subpath-imports.md
vitejs/vite#8575
https://davidwells.io/blog/publishing-flat-npm-packages-for-easier-import-paths-smaller-consumer-bundle-sizes
https://stackoverflow.com/questions/44345257/import-from-subfolder-of-npm-package/61829317#61829317

[irahopkinson]

Thanks for adding this @rolfheij-sil. I did look into this when working on #179 but it wasn't clear to me that flat paths actually effect bundle size, in fact some people say it doesn't help at all and is separate from bundling. In the end I left it out because we are using tree-shaking and I know (from testing) that does remove any unused parts of papi-components. Even for lodash (which was given as an example of flat paths in one of the linked articles) warns that it might help but it might not, e.g. if you import lodash/<A> and lodash/<B> that have a common dependent function then you will get 2 copies of that dependent function, whereas if you just import A and B from lodash directly and tree-shake then the total bundle size will be smaller because it will only have one copy of the dependent function. So I would recommend tree-shaking for extension developers at the moment. Having said that this might still be useful to do as it is the modern way of importing sub-components of a package, and esp if we can show it does make a difference to bundle size.

[tjcouch-sil]

I recommended this as it would make it a lot easier to understand what types and such come with which component. However, if there are disadvantages as you mention, maybe we should leave it alone. Can we do some kind of namespacing with another method to avoid throwing tons of disparate types all in one module? Thanks for the thoughts!

[tjcouch-sil]

Maybe we should consider subpaths for scripture utilties and hooks (assuming we end up putting hooks in here as I have been thinking maybe we should do) to keep things organized. Like here https://reviewable.io/reviews/paranext/paranext-core/468#-NfRW7MxE475_NAOStBG it's all at the same level, but that seems really hard to keep track of what's what.