feat(docs): abstraction support for documentation parsers

[sudojunior]

Documentation providers

Package	Planned	Supported	Website	Repository	Manifest
slash-create	✅	✅	slash-create.js.org	Snazzah/slash-create	Snazzah/slash-create@docs
discord.js	✅	✅	discordjs.dev discord.js.org	discordjs/discord.js	discordjs/docs
eris	❌	❌	abal.moe/Eris	~/data/docs/index.json	~/eris-{version}.json
@sapphire/*	✅	❌	sapphirejs.dev	sapphiredev/framework sapphiredev/shapeshift	sapphiredev/docs

Other providers not yet in scope

• https://github.com/twitterjs/twitter.js (docgen)
• https://github.com/zlddev/quickmongo (discordjs/ts-docgen)

Generator Formats

• typedoc
• ts-docgen (from typedoc)
• docgen
• openapi

By supporting slash-create, dbots.js and dbothook.js.org are also supported and were added with the navigator rewrite in #70. Per-package embed libraries are already possible, .

Additional safeguards to protect the service from throwing errors can include prevention of attempts to search or fetch from specific providers for /docs or /code as standard options or an opt-in basis. Navigator abstractions will also be needed due to the differences in docgen structure (i.e. SlashCreateDocsParser + SlashCreateDocsSource + SlashCreateDocsNavigator).

[sudojunior]

Options to review at a later date

• Utilize dependency injection containers for handling provider abstraction. The long term benefits would greatly improve the assignment of tasks to each group (with the option to group by format rather than by package or author).
• XML, YML, TOML or JSON for provider spec (moving the home and creation of each provider away from Provider)

As mentioned in #74, supporting eris will be a challenge under the current codebase - for which it would benefit greatly with the above in place, with less complications of how classes handle navigation and more options and accessibility.

[sudojunior]

• Provider(options: ~, parent: never) independent
• ProviderGroup / ProviderHub coordinator
  • ProviderMember(options: ~, parent: ProviderGroup) member