Implement `dolt_help` set of system tables

[timsehn]

We should have a dolt_help system table with the following schema:

target (key): ie. dolt_checkout, dolt_diff, dolt_hashof, etc
type: system table, procedure, function, variable
short description: the short help text
long description: long help text
arguments: a json blob describing the arguments

This would help move our documentation in product and be generally useful. We could even generate the docs site documentation from this code.

[milogreg]

Hey, I've been working on this a bit, but had a few blocking questions about how things should be structured.

---

Should the short and long help texts be copied directly existing markdown docs, or should new plaintext-readable docs be created based on them? If automatic docs site generation is a priority then I'm assuming at least the long help text will need to be markdown.

---

Storing procedure arguments in JSON would be straightforward as they pretty much fit the CLI model of {argument:description}, but It's a little ambiguous how function arguments should be structured in JSON. I'm assuming that the argument JSON for functions would contain a list of parameter layouts and a list of arguments. It's clear that individual arguments should have a description, but there is some argument behavior that doesn't fit neatly under a specific named argument or spans multiple arguments (see the argument description of DOLT_REFLOG). Should there be a global description that applies to all layouts and arguments, per-layout descriptions that apply to all arguments within a given layout, or both?

---

If the docs will eventually be generated using this table, then whatever populates the table will become a new original source for the docs, and will need to be edited directly to change them. Is there a preferred location/format for this docs source?

A few options for location are:

• Docs stored as string literals in the go code (like the CLI help text). This would be pretty ugly for markdown docs, as the commonly used ` character breaks a multiline string and can't be escaped.
• Docs stored as many external files (one for each string required in the go code), which are embedded in the go code.
• Docs stored in fewer external files (such as one for system tables, one for functions, etc), which are embedded in the go code and parsed into smaller components.
• Docs stored in the dolthub/docs repo, which are embedded in the go code. This would likely require an additional build step, as //go:embed can only embed local files.

A few options for format are:

• Docs stored as strings which will have minimal processing done on them.
• Docs stored as strings with templating to allow changes in the names of system tables, functions, function args, etc. in the code to apply in the docs.
• Arguments stored in their final JSON format.
• Arguments stored in a non-JSON format and parsed into JSON.

[zachmu]

Should the short and long help texts be copied directly existing markdown docs, or should new plaintext-readable docs be created based on them? If automatic docs site generation is a priority then I'm assuming at least the long help text will need to be markdown.

No markdown or other formatting directives in the SQL tables, it doesn't make sense in that context. Docsite generation isn't a big priority -- we already generate the doc site from the same source that these new help tables use, so it doesn't add anything.

Storing procedure arguments in JSON would be straightforward as they pretty much fit the CLI model of {argument:description}, but It's a little ambiguous how function arguments should be structured in JSON. I'm assuming that the argument JSON for functions would contain a list of parameter layouts and a list of arguments. It's clear that individual arguments should have a description, but there is some argument behavior that doesn't fit neatly under a specific named argument or spans multiple arguments (see the argument description of DOLT_REFLOG). Should there be a global description that applies to all layouts and arguments, per-layout descriptions that apply to all arguments within a given layout, or both?

There is too much ambiguity and variability around arguments for them to have a standard structure, you're expected to read the long description and synopses to understand the various forms of a command like dolt branch. For now, I would just omit any arguments in the JSON payload and only focus on the options (flags).