refactor: consolidate two conditionals

First one I wrote because that's the natural order that it occurred to
me as I was writing it. Second one because I needed to keep TypeScript
happy.

But I can consolidate them into one thing, and TypeScript will still be
happy.

test: add tick() implementation to skip time in integration tests

fix: correct TypeScript type annotation for custom matcher

TS was accepting this, but warning that my `await` on the matcher had no
effect. Obviously a bad annotation.

refactor: move integration tests "table of contents" to top

Seeing as everything that follows it is basically an "implementation
detail", we want it to be the first thing you see when you land in the
file.

refactor: sort functions alphabetically

test: teach integration tests how to save/check/update snapshots

All pretty quickly hacked together but seems to work, at least in my
light manual testing of it.

feat: actually record project UUID when creating tasks

chore: update dependencies

Note minor formatting changes for compatibility with the newer version
of the `prettier` package, and also a config tweak needed due to changes
in the ESLint plug-in:

    https://github.com/prettier/eslint-config-prettier/blob/main/CHANGELOG.md#version-800-2021-02-21

Also note that I actually had to delete the `yarn.lock` and regenerate
it from scratch in order to silence a bunch of `yarn audit` warnings.

test: add first basic test script

Just showing that we can parse commands and run them (not doing
comparison or auto-update yet).

feat: add simple shell syntax tokenizer

Yeah, maybe should have called this `tokenizeShell()` but seeing as I
already have some functions named `parseSomething()` I maintained the
pattern here. It really isn't doing anything fancy (like parameter
expansion, for obvious reasons); rather, it is just breaking the input
up into words in the "shell" sense.

Will be using this to process our integration test scripts.

test: prepare skeleton for running integration tests

Seeing as `next` interacts so heavily with the file system I want to
write some "full stack" integration tests to exercise the whole thing
and then inspect the results on the file system. Not really doing
anything in here yet, but this is the basis for being able to invoke the
command-line (kind of -- we're actually just importing `main` and
calling it) in a temporary directory.

I still need to think about how I want these "scripts" to actually look.

feat: add mulberry32 PRNG

Going to need this in integration test suite, because I want to be able
to generate fake (not truly random) UUIDs based on a fixed seed (ie.
always get the same results on every run).

style: fix formatting

fix: don't overwrite existing tasks

fix: make sure newly created projects have metadata

fix: correct a couple of random problems

- Eliminate lint errors about unexpected empty functions
- Make sure newly added items don't have a spurious completion date

feat: teach Store some more stuff

File under "Great Commit Messages of Our Times".

feat: continue fleshing out Store class

feat: start fleshing out "init" subcommand

Again, this is a very WIP thing just because I want to get something in
the repo (I don't trust this machine).

feat: start fleshing out Store abstraction

So this is a bit of a mess but I wants to show a rough sketch of the
direction I'm heading in with the data directory layout and subcommands
to interact with it. Current status: it runs, and that is about the only
nice thing I have to say about it.

docs: move subcommand docs into subfolder

chore: add notes for how to initialize worktree with minimum fuss

docs: add a couple more desired commands to docs/DESIGN.md

feat: add UUID()

feat: pass richer context to subcommands

Because I am going to need this very soon in order to access the data
directory.

feat: add some Markdown formatting of sample docs

feat: wire up help logic

"Wire" (chicken wire) being the operative word here.

fix: remove duplicate named exports

feat: allow subcommands to specify additional options

refactor: use terser format for dynamic import

feat: wire up initial sucbommands

Although note, they don't do anything yet.

feat: load config from -c/--config file, if specified

feat: add simple option parsing

In preparation for running subcommands.

feat: add `yarn build:force`

Seems that with incremental compilation and/or `--watch` (I am not sure
which), `tsc` will sometimes consider that there is nothing to do, even
if you blow away the buildinfo file. So add this "nuclear option" script
to force it to build no matter what.

refactor: provide Config type to represent normalize rc-file contents

chore: add repo to nextrc file

To support two main use cases:

1. In a project with tasks on a branch in a worktree:

   branch = todos
   repo = .
   worktree = todos

2. Global TODOs set up in home directory:

   branch = master
   repo = ~/school/todos

In practice, I think repo can default to "." and branch to "master" if
not specified. Not sure whether we should assume use of worktree in case
1 (eg. infer it from branch?); it's probably better to just make it
always explicit.

fix: handle full range of `git worktree list --porcelain` output

- Drop `HEAD`, which doesn't seem to be useful.
- Explicitly support `detached` and `bare`.
- Keep `path` and `branch`; gracefully accept (and ignore) everything
  else in the name of future-proofness.

chore: turn on incremental compilation and add a watch mode

test: make sure jest doesn't run twice

It was running on source files in "src"/ and also on built files in
"lib/", which could yield the confusing situation of seeing "src/" tests
pass (because they've been fixed) but "lib/" tests fail (because you
haven't run `yarn build` yet). This is particularly confusing if running
the tests with `yarn test --watch`, because it drives up the odds of
running the tests before you've done a build to near 100%.

fix: handle edge cases in StringScanner#location reporting

Literal edge cases at beginning of start and end of string.

While testing `git worktree list --porcelain` output in order to handle
all the possibilities mentioned in `man git-worktree`, noticed my
reporting was off by one line when the expected token was not found at
the start of the line.

After I fixed that and started looking at error reporting for INI
parsing, noticed an edge case at the opposite end (ie. the end of the
input string).

Finally, found one more edge case and fixed that. Added a regression
test for each one.

feat: add "clean" script

test: add test for subprocesses exiting due to a signal

Too lazy to do this before, but then had the idea for how to do this
simply.

feat: plumb in basic check for git-worktree

With some TODOs and a missing `prompt()` implementation still to do.

test: revert to previous fix

Sigh; the uglier fix is apparently still necessary:

    https://github.com/wincent/next/runs/1622754433

This reverts commit b360877f10c03c002360243264b5e8efab8aae26.

refactor: apply neater fix for Node v10 failures on CI

test: attempt fix for CI failure on Node v10

Example failure here:

    https://github.com/wincent/next/runs/1622716501

feat: add loadRC() function

Note that I made it take a `from` parameter because I thought that
might make it easier to test, but in the end I didn't make real use of
it; I might remove it in the future.

feat: add dev-only helper to catch resource staleness

docs: add `next init` to wishlist

feat: add basic INI parsing

chore: configure Prettier to ignore built files

docs: add CI status badge to README.md

feat: add "ci" script

For running basically the same tests locally (except the lockfile check)
that GitHub actions will run.

feat: set up CI

feat: set up linting

test: set up basic test infra

I hate the dependency footprint here, but it still seems like the best
option.

As evident from the diff, the "blinking light" demo for the future
`parseINI()` module shows that we can run tests.

style: manually prepare tsconfig.json for future formatting

Because any directive I uncomment in the future will have Prettier
moving the trailing comment on the next format run, I may as well do
them all ahead of time.

style: format generated file

feat: add stub executable

chore: add stub tsconfig.json file

Created with:

    yarn tsc --init

docs: add initial seed of design draft document

chore: set-up basic project dependencies

We don't want any runtime deps beyond NodeJS itself, and we want the
number of dev-time deps to be very small; Prettier to keep the code and
docs looking nice, and TypeScript to actually build from source. At a
later time I will probably add a test runner (could be Jest, although it
has an annoyingly enormous dependency graph, so I might end up picking
something more minimal, at least to start with).

chore: seed "master" branch with MIT license file