Expose template to user

[ethankhall]

This change exposes the templates to the users more fully, allowing them to customize the output entirely.

It also removes the ReportDefinition and moves all the config to a location. In theory we could use the ReportDefinition as a base, but in most cases I don't think that's worth the complexity, if people want to re-use config, the should be able to use yaml anchors to do it.

Todo:

• [x] Make a command to render the template with a "full" sample, to validate all report templates
• [x] Update docs on what variables are present at each template run.

[ethankhall]

Created a new lint subcommand, maybe be useful in other places too...

> scope lint --help
Validate inputs, providing recommendations about configuration

Usage: scope lint [OPTIONS]

Options:
  -v, --verbose...
          A level of verbosity, and can be used multiple times

      --progress <PROGRESS>
          Set the progress output. Use plain to disable updating UI

          [env: SCOPE_OUTPUT_PROGRESS=]
          [default: auto]

          Possible values:
          - auto:  Determine output format based on execution context
          - plain: Standard output, no progress bar, no auto-updating output
          - tty:   Use progress bar

      --otel-collector <OTEL_COLLECTOR>
          When set metrics will be sent to an otel collector at the endpoint provided

          [env: SCOPE_OTEL_ENDPOINT=]

      --extra-config <EXTRA_CONFIG>
          Add a paths to search for configuration. By default, `scope` will search up for `.scope` directories and attempt to load `.yml` and `.yaml` files for config. If the config directory is somewhere else, specifying this option will _add_ the paths/files to the loaded config

          [env: SCOPE_CONFIG_DIR=]

      --disable-default-config
          When set, default config files will not be loaded and only specified config will be loaded

          [env: SCOPE_DISABLE_DEFAULT_CONFIG=]

  -C, --working-dir <WORKING_DIR>
          Override the working directory

      --run-id <RUN_ID>
          When outputting logs, or other files, the run-id is the unique value that will define where these go. In the case that the run-id is re-used, the old values will be overwritten

          [env: SCOPE_RUN_ID=]

  -h, --help
          Print help (see a summary with '-h')