Hi there! Here's an org-parser in pursuit of #66.

Why?

In order to support org-mode with minimal refactoring, I decided to copy the Markdown parser & make minimal changes to it to make it work. I also copied the test suite and made minimal changes there.

What does this PR contain?

• a package that parses tasks in org-mode documentation (parseorg), following the pattern from Markdown
• new behavior to detect which parser to use based on documentation file suffix (.md vs .org)
• a new CLI flag (-type {md,org}) to select a parser explicitly (overriding file suffix, if any)
• if no file provided, xc searches for either README.md and README.org in current directory & parents (with preference for README.md, if both exist, to minimize potential for breaking change; though breakage is still possible, given that the tool would currently skip over a directory containing README.org and find a parent containing README.md, but would stop earlier after this change)
• documentation updates to support users of xc & org-mode

What's next?

I have tested it thus far by running go test ./... and by running it on various of my own org and md files. It could use some more testing.

At this stage I welcome feedback on any aspect of the approach, code organization, testing, etc. If you are worried about code duplication, I was thinking about doing another pass after getting the thing working to deduplicate and refactor the parsers somewhat. The approach I've favored has the benefit of minimizing code changes for Markdown users, reducing the potential to break the current behavior.

Notes on differences from md behavior

These are documented for end-users in ABOUT.org

• Comment headings
  org-mode supports comment headings, which begin with COMMENT and are intended to be skipped over during execution. I've added some logic to honor this for headings that would otherwise be counted as task headings (see example here, and notice that in the rendered view GitHub correctly skips rendering that heading.)
• Header tags
  org-mode has an explicit affordance for hidden markers attached to headlines: tags. I decided to look for a :xc_heading: tag on a heading rather than an HTML comment. Here's what it would look like in practice:

  ** Getting started                          :xc_heading:
    *** build
      [...etc]