Implement interface for meltano `validator` plugins

Related to #2454, we will need a spec for how validators should interface with meltano CLI.

As part of the spec definition, we're looking at how the following validators would work:

- Great Expectations (full)
- `dbt test` (native dbt feature)
- Stream maps
- SQLFluff - (potentially as this could be considered a code validator)

## Latest Proposal (2021-12-07):

Similar to the below from 2021-10-27, except that there is no "top level `tests:`" config. Instead, "plugins" `have` "commands" and "commands" `can be of type` "test". A command is of type `test` if its name starts with the word `test`.

## Older Proposal (2021-10-27):

* Discussion of the proposed spec from this comment thread: https://gitlab.com/meltano/meltano/-/issues/2838#note_682557413

1. Already today: **Any plugin type can have a `test` command, added inline with other commands using existing command syntax.**
1. Already today: Each test command is invocable directly and can perform its actions based on just environment vars and other context such as command line args.
1. New: **Any plugin with a `test` command can also have a `tests:` list entry in the top-level plugin config.** Each item in the list of `tests` can have the following properties:
    1. `name` - optional, if test is to be referenced by name
    2. `executable` - optional, overrides the executable of the default `test` command at the plugin level
    3. `args` - optional, overrides the args of the `test` command at the plugin level
    4. `env` (or `vars`) - a list of env variable name/value combinations to be passed to the executor
1. New: Tests could be invoked with any of the following syntaxes:
    1. `meltano run <plugin>:test` - runs any and all tests defined in the plugin declaration.
        - If the `test` command exists but no `tests:` declaration, only the one test command will be executed.
        - If the `tests:` entry also exists, all enumerated tests will be run in order.
        - If the `test` command does not exist, the command fails.
    2. `meltano test --all` (a new cli command) runs all defined tests in all plugins.
    3. `meltano test <plugin>` runs all defined tests for the named plugin.
    3. `meltano test <plugin1> <plugin2>` runs all defined tests for the named plugins.
    4. `meltano test <plugin>:<test-name>` runs a named test for the named plugin.
    4. `meltano test <plugin1>:<test-name1> <plugin2>:<test-name2>` runs multiple named tests for the named plugins.

Future Considerations:

Sequencing would need to be provided explicitly in the `v1` release, but `depends_on` behavior could be added in a v2, perhaps after `environments` (#2869) is released.


<details><summary>Previous proposals, click to expand</summary>
## Option A: Dedicated CLI command `meltano validate` (confirmed first iteration)

This would run validations as a dedicated top-level command. How the integration is performed would be governed by (a) custom code in meltano library and/or (b) configuration specs in the `validators:` entry in `discovery.yml`.

## Option B: Integration with `meltano elt` (won't do, deprecating in favor of `meltano run`)

Could be enabled/disabled similar to how transforms are treated, with a CLI flag.

## Option C: Integration with (WIP) `meltano run` (will do, but in future iteration)

Could be listed in a pipeline definition such as:

`meltano run tap-salesforce target-snowflake dbt:test ge:test`

Given an invocation such as the above, Meltano may be able to infer that the two validators can run in parallel, and may automatically parallelize them.
</details>

Story points: 12.0