Add typedoc to include JSDoc comments in Docs site

[nabbydude]

Description

Docs have drifted out of sync with the codebase, many functions are entirely undocumented. Added typedoc package to convert JSDoc packages to doc API pages. Goal with this PR is not to write new documentation, just convert existing documentation and scaffold some basic doc architecture, then once this is merged contributing docs can be more seamless for everyone. This also means scope is just limited to API docs, and doesn't touch guides, concept pages, etc

Creating a draft so I can document and plan architecture decisions and get feedback.

Issues

Implements #3319
I'll also hopefully address these bc they seem doc-related:

• Not clear docs on Node.common() #5520
• Slate docs site has bad UX #5350
• Docs: Make it specific that Editor.nodes relates to the current selection. #3885
• Incorrect return type for useSlateStatic #5404
• The "at" option in the Transforms API does not work as expected when passing editor.selection explicitly #4718
• Explain a quirk with reference to node objects #3802

To-do

• Implement typedoc
  • Configure to as-good-or-better-than-current state
  • Ensure output is reasonable and sane (no unreadable types, dead links, etc)
• Convert existing API docs to JSDoc comments
  • locations
    • Location
    • PathRef
    • Path
    • PointEntry
    • PointRef
    • Point
    • RangeRef
    • Range
    • Span
  • nodes
    • Editor
    • Element
    • NodeEntry
    • Node
    • Text
  • operations
  • scrubber
  • transforms

Decisions

Custom Types

How to show eg Editor vs BaseEditor in the docs. I think what makes most sense to me would be to redirect Editor to BaseEditor and explain the distinction at the top of the page but idk yet how possible that is in typedoc. If not, the former could just be a stub that links to the latter. Further complicated by next heading:

Static helpers vs Types

Element is a type of node with a children property, but Element is also a const collection of static utility functions for element nodes. How to square this in docs? I could see the helper being renamed to either its type (ElementInterface in this case) or something like "Element Helper" With a clarifying note at the top of the Element page.

Multiple overlapping definitions

collapse is exported 3 times by slate, as a standalone static function, as a static member of the Transforms helper, and as an instance method of the BaseEditor object. Ideally we wouldn't have to write the same documentation 3 times.
Currently under the hood the helper method just redirects to the instance method, then the instance method calls the bare method, but could be overwritten by plugins/users. idk for sure if the bare methods are even intentionally exported, I've certainly never used them but curious if anyone else does. As a bonus collapse is also in the SelectionTransforms helper, which is merged into Transforms externally but still referenced by name internally.

Checks

• The new code matches the existing patterns and styles.
• The tests pass with yarn test.
• The linter passes with yarn lint. (Fix errors with yarn fix.)
• The relevant examples still work. (Run examples with yarn start.)
• You've added a changeset if changing functionality. (Add one with yarn changeset add.)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 797e0fc

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR