circleci config process should print jobs available and their parameters

## What problem does this feature solve?:

I want to test parameterized jobs from the circleci CLI without having to figure out which auto-generated job name to use.

Why is this a cumbersome limitation:

`circleci config process` generates one job in the output for each parametrized job that appears in the workflow.

Eg if job A accepts parameter B, and workflow specifies two jobs that use A, with B values "abc" and "def", then the output will have a job named `A-1` which is job A with B=abc, and another job named `A-2` which is job A with B=def.

Unfortunately, which auto-generated job corresponds to the desired combination of values of job parameters that I want to test can only be inferred by finding which generated job code has the values I want, rather error-prone.

Only once I know the generated job naem will I be able to run eg `circleci local execute A-1`.

Solution:

`circleci config process` should output which job names were generated, and what were the job parameters used for each one
it should therefore not output to stdout, instead it should require a file name.

## Provide an example:

In `config.yml`, say I have this:
```
jobs:
deploy:
parameters:
env_name:
type: string
default: devops1
docker:
- image: cimg/base:2021.07
user: root
steps:
- checkout
- run:
name: Deploy to << parameters.env_name >>
command: ls

workflows:
version: 2.1

auto-deployments:
jobs:
- deploy:
env_name: dev
- deploy:
env_name: dev2
```

then `circleci config process INFILE --out OUTFILE` would create OUTFILE instead of outputting it to stdout, AND stdout would show something like this instead:
```
$ circleci config process .circleci/config.yml --out /tmp/cci-config-processed.yml
auto-generated jobs:
deploy-1:
env_name: dev
deploy-2:
env_name: dev2
```
Then I would automatically know that `circleci local execute --job deploy-1` will test `deploy` with parameter `env_name` = `dev`

Start at the implementation of the `circleci config process` command and trace how generated job names and processed configuration output are produced. Compare the behavior with the example using `--out`; done means the command reports each auto-generated job with its parameter values while writing the processed configuration to the requested file.

Written by the indexing model from the issue text.