new CLI interface#10

I have the impression that the cli commands need to be better designed. Ideally, a developer should not need to know how things work internally (pull/push/define). Instead, they should intuitively know what commands to call for their most basic operations and that intuition should come from standard procedures of other workflows, such as `build` and `deploy`. In some ways the `dev` command tries to do that but it's just not good enough. ## Proposal ```haskell --- first level commands: --- build [directory] [NEW] deploy [directory] [NEW] dev [directory] [???] reset [KEEP, but add possibility to choose what parts should be reset (optional)] --- second level commands: --- define-functions [pattern] [KEEP] define-indexes [pattern] [KEEP] define-roles [pattern] [KEEP] pull-schema [output] [KEEP] push-schema [pattern] [KEEP] generate-types [pattern] [output] [REMOVE - it doesn't seem to be useful after all] build-sdk [schema-pattern] [documents-pattern] [output] [KEEP] --- others: --- help [command] [FIX - it has never worked] ``` 1. The `build` cmd would only run local operations (for a start, it would only call `build-sdk`) and provide the resources needed in the development workflow. 1.1. No side-effects to the database allowed; 1.2. Therefore, no need to have a secret key and thus it could be used in any regular build script (e.g. `npm prepare`) 2. The `deploy` cmd would run all the operations that result in changes in the database, currently `define-*` and `push-schema`. 3. Both `build` and `deploy` would have the option to flag with `--watch` to become more developer-friendly. 4. The `generate-types` is cool, but what use case does it cover? The sdk is already covering all practical use cases I can think of. Only in a case of extreme modularization and code reuse is that I could envision some use for this. It's time to kill it. ## Challenges * We can't create a `build` command without side-effects to the database until https://github.com/zvictor/faugra/issues/1 is fixed. Until then, a fauna secret needs to be provided in order to generate the sdk. ## Questions * How can we make a clear distinction between first and second levels? _I thought on grouping "second level commands" as subcommands (e.g. wrapping them all under `run` as in `npx faugra run define-functions [pattern]`), but it doesn't look sexy enough._ * What should be done with the `dev` cmd? If both `build` and `deploy` have the `--watch` option, what is the point of `dev` other than just putting both cmds together?