Use subparsers/subcommands for experiment CLI

[WarmCyan]

As the CLI becomes more complicated, and there are additional plans to make it more complicated, putting everything into the same base parser is becoming confusing.

It's convenient to be able to just type experiment [my_experiment_name], but as the number of possible "commands" grows (e.g. experiment reports, experiment ls), the potential for conflicting names also grows.

reports and ls should be put as sub commands, and a new run subcommand should be added for the primary run-the-experiment usecase.

Thoughts on this are welcome, it unfortunately is a breaking change for any prior experiment's reproduction lines.

[WarmCyan]

Once this goes through, it might actually be worth moving the curifactory commands (project.py) into the experiment command instead, e.g.

curifactory init -> experiment init
curifactory completion -> experiment completion

Similarly, some of the flags could probably just become subcommands instead. Specifically

experiment [...] --map -> experiment map [...]
experiment [...] --check -> experiment check [...] (once #81 done)

Other sub commands might include:
experiment reset [...] (#70)

[WarmCyan]

This should also allow two important functionalities:

• Print out associated cache paths for a particular run
• Print out the parameters registry for a hash starting with ...