feat(cmd): Add CLI Tool

[jshlbrd]

Description

• Adds a substation CLI tool built on cobra
• Adds a substation demo subcommand to the CLI tool for demoing data transformation
• Adds a substation test subcommand to the CLI tool for unit testing configs

Motivation and Context

This closes #241 and closes #239. Tests are implemented using a custom schema, like this:

local sub = import '../../substation.libsonnet';

{
  tests: [
    {
      name: 'my-passing-test',
      // Generates the test message '{"a": true}' which
      // is run through the configured transforms and
      // then checked against the condition.
      transforms: [
        sub.tf.test.message({ value: {a: true} }),
      ],
      // Checks if key 'x' == 'true'.
      condition: sub.cnd.all([
        sub.cnd.str.eq({ object: {source_key: 'x'}, value: 'true' }),
      ])
    },
  ],
  // Copies the value of key 'a' to key 'x'.
  transforms: [
    sub.tf.obj.cp({ object: { source_key: 'a', target_key: 'x' } }),
  ],
}

Each test defines a custom message (using transforms) and assertion (using a condition) that is sent through the transforms array.

There is no setting to bypass tested transforms; instead, users should mimic software development best practices and try to make their tests as small as possible by breaking up their config into smaller components (this is consistent with our documented guidance, too).

NOTE: It would be a bad idea for users to test transforms that mutate production resources, but we can't control that.

The CLI tool should be considered experimental and does not require breaking changes to be tracked using SemVer. (Versioning is still accurate in this case.)

How Has This Been Tested?

• substation test was integration tested for a variety of use cases:
  • Tested individual files
  • Tested directories
  • Tested nested directories
  • Tested config errors
  • Tested test failures
  • Tested test successes

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.