docs: API Reference

[AlexStormwood]

Make sure everything that is "user-facing" has JSDoc comments, and implement a CICD pipeline to compile that into a deployed website.

API Sections

Confirm that the sections are in-use in the project, and document them.

• [x] Guides
  • [x] Quick Start
  • [x] The Basics
  • [x] 00 - Understanding This Package
  • [x] 01 - The SuperCamo Singleton
  • [x] 02 - Document Basics
  • [x] 03 - Embedded Document Basics
  • [x] 04 - DB Client Basics
  • [x] Package Exports
• [x] Reference
  • [x] Classes:
  • [x] CollectionAccessor
  • [x] CollectionListEntry
  • [x] NedbClient
  • [x] SuperCamo
  • [x] NedbBaseDocument
    • Make sure to note that TypeScript intellisense shows more data (eg. rules) on a CTRL+Space shortcut in VSCode
  • [x] NedbDocument
  • [x] NedbEmbeddedDocument
  • [x] Interfaces:
  • [x] BaseDocument
  • [x] CollectionAccessor
  • [x] CollectionsListEntry
  • [x] DocumentBaseData
  • [x] DocumentConstructorData
  • [x] DocumentKeyRule
  • [x] DocumentObjectData
  • [x] findManyDocumentsOptions
  • [x] findManyObjectsOptions
  • [x] findOneObjectOptions
  • [x] NedbClientEntry
  • [x] updateManyOptions
  • [x] updateOptions
  • [x] Logging:
  • [x] SuperCamoLogger
  • [x] Error Classes - might just leave these as-is for now, they only really exist for catch specificity anyway

Automation

GitHub Actions workflow requirements.

• [x] Repo configured with GitHub Pages deployment.
• [x] Repo configured with a JSDoc build command.
• [x] Workflow configured to run the above JSDoc build command.
• [x] Workflow configured to upload JSDoc build output to gh-pages branch.

[AlexStormwood]

Some sections (mostly in Interfaces) don't show their explanation content in the generated website, but that's fine - it's nothing that package users are meant to be using anyway. And if they do need to dig into it, then the JSDoc comments/intellisense in their coding editor will work to provide info as a workaround instead.