Task commands read and write tasks the way Logseq does #92

After this, every command that deals with tasks agrees with Logseq on what a task is and what state it is in, and a caller gets the same answer from each of them. Today each command decides this on its own, and several disagree with Logseq and with one another.

What happens today

• analyze-graph counts more open tasks than get-todos lists. It searches the page text, so a block starting with [ ] and a line like TODO: count as tasks, although Logseq reads neither as one.
• set-todo-status on a heading task (## TODO x) writes DONE ## TODO x. On a block without a marker it adds one, so plain text becomes a task.
• get-todos without --status leaves out tasks marked WAIT, WAITING, IN-PROGRESS or STARTED, and set-todo-status cannot set WAIT or WAITING.
• A task with a date cannot be written through --content: the SCHEDULED: line becomes a block of its own.
• On a repeating task, --status DONE always ends the repetition. Logseq offers two ways: ticking the checkbox moves the date on and logs the completion, /DONE ends it. The CLI offers only the second and does not say so.
• The habit section of analyze-journal-patterns reads lines that Logseq shows as plain text, not as checkboxes.

Why it happens

Logseq has one idea of a task: a block with a marker, drawn as an open box, a ticked box, or struck through when cancelled. The CLI keeps five different marker lists and reads tasks from two sources, the database in get-todos and text patterns in the analysis commands. Every finding above follows from that. A caller who compares two commands, or checks one against Logseq, gets contradicting answers and cannot tell which is right.

What changes for a caller

• A task is what Logseq reads as a task, and its state is open, done or cancelled, as Logseq draws it. All task commands take both from one place.
• get-tasks (today get-todos) lists all open tasks by default and filters by state. set-task-status (today set-todo-status) changes only tasks, writes heading tasks correctly, and on a repeating task asks which of Logseq's two ways is meant. The old Command Names stop working in the release that carries the rename, with no second name left behind, so a script that calls get-todos or set-todo-status has to change.
• analyze-graph and analyze-journal-patterns count tasks from the same source as get-tasks and count checkboxes separately. Repeating tasks and their completions replace the habit section. Some JSON keys of both commands change, and the changelog names them.
• A task written with a SCHEDULED: or DEADLINE: line keeps it.

How to tell it is done

• analyze-graph reports the same number of open tasks as get-tasks, and
  both match Logseq's own (task …) query on the same graph.
• A caller can list and filter WAIT, WAITING, IN-PROGRESS and STARTED tasks
  like any other, and set every marker Logseq's editor offers (all but
  STARTED, which Logseq reads but its editor does not know).
• A repeating task can be ticked off so that its date moves on, with the same
  text Logseq writes when its checkbox is ticked.