[Strategy] Come up with config schema, basically

[mikedotexe]

We want to have a configuration file that resides in a place oclif helps us get the path to.

That location is basically:
/Users/mike/.config/csli

I'd like to see the global config file live at:
/Users/mike/.config/csli/csli-cli.json

But we also want to have interactions with settings that belong in a project.
So there might also exist a file like this:
/Users/mike/hacking/cross-contract-example/csli-cli.json

and when I go into the cross-contract-example directory in my terminal and type csli into the prompt, I want it to load the project settings and my global settings, and come up with a reasonable conclusion about how to proceed with my command.

---

Here's my thought, put into form in an example where we'd like to see how the config files might change the verbosity of a given command. Let's use tx, I suppose.

So the end user types csli tx haShAbc123…

csli looks in the cross-contract-example project and see's there's a csli-cli-.json file there, so it loads it. It might see this:

{
  "majorVersion": 0,
  "tx": {
    "verbosity": "medium"
  }
}

This alone means that, if there's no global config to load, the csli CLI program's default of "low" would be overridden and the new default becomes "medium"

If there is a global config to load, and that global config looks like this:

{
  "majorVersion": 0,
  "defaults": {
    "tx": {
      "verbosity": "high"
    }
  },
  "overrides": {
    "block": {
      "verbosity": "low"
    }
  }
}

Then we do not override the value and the command will run with "medium" verbosity because of the config file in the project directory.

Note that the global config has a defaults key, and those are used when a project doesn't have a config. But you must place a setting in the overrides key in order for it to supplant all settings.

It seems like if we follow semantic versioning, we can just keep track of the major version in the config file itself. Perhaps we even name these files prefixed by the major version. Like:

/Users/mike/.config/csli
                     ├── 1-csli-cli.json
                     └── 2-csli-cli.json

---

Why are we spending so much thought on this? It's a good question.

Smart contract project codebases are rather unique, and I believe we can show that projects that invest time into getting their settings tuned to display their activity, will find success in building, debugging, QA'ing, etc.

So this is more than just config. This time, it will contain instructions on how to "set the stage" for your eyes to visually see the behavior of this animal.