Support `meltano shell` command to spawn terminal in plugin context

## Change Log

- 2021-11-17: Added feedback from @edgarrmondragon and Docker ideas.

### Problem to solve

In order to improve productivity of developers using plugins within a Meltano Project, we could support a `meltano shell` command that spawns a terminal session inside the plugins context. This enables users to benefit from Meltanos config, virtual-env and environment management features in a simple and intuitive way (i.e. without having to prefix each plugin invocation with `meltano invoke`).

### Target audience

Developers, Data Engineers, Data Scientists and Analytics Engineers working within a Meltano Project.

### Further details

This would compliment the recently added `--environments` [feature](https://meltano.com/docs/environments.html#environments), allowing users to get on with _using_ wrapped tools without having to worry about configuration, virtual-env and dev/prod environment differences. It also cuts down on redundant setup/teardown operations on each `meltano invoke` invocation (e.g. Airflow `initdb` [here](https://gitlab.com/meltano/meltano/-/blob/master/src/meltano/core/plugin/airflow.py#L108)), and allows us to set up other convenience features like autocomplete etc. in the shell context. Users may wish to have control of the development environment for each plugin, including adding additional tools for tests, linting etc. (e.g. SQLFluff with dbt).

This may also be an opportunity to support Docker containers for development. `meltano shell` may just as easily implement an equivalent of `docker run -it fishtownanalytics/dbt` as `source /path/to/dbt/venv/bin/activate`. This may reduce the impact of cross-platform tooling support and configuration differences.

### Proposal

Example workflow for adding a new data integration using Meltano, dbt and Airflow:

```shell
$ git checkout -b 2345_add_gitlab_to_hub_pipeline

# find a tap that matches the source I want to integrate
$ meltano discover extractors
> tap-gitlab
> ...

# add and configure the tap
$ meltano add extractor tap-gitlab
$ meltano config tap-gitlab set projects "meltano/meltano meltano/sdk"
$ meltano config tap-gitlab set start_date 2021-10-01T00:00:00Z

# now lets create a schedule
$ meltano schedule gitlab-to-postgres tap-gitlab target-postgres @daily

# and run a sample extract in my development environment, so dbt has data
$ meltano --environment=dev_kp elt tap-gitlab target-postgres --job_id=gitlab-to-postgres

# with a new extractor added and data extracted,
# lets update our dbt models for the new source...

# activate a console within the 'dbt' virtual env created by Meltano Project,
# using secrets/env vars from my personal dev environment
$ meltano shell dbt --environment=dev_kp

# luckily a postgres-compatible dbt package exists for the tap I just added 😅
$ nano packages.yml
> packages:
  - package: dbt-labs/gitlab
    version: 0.7.0

$ dbt deps

# run the new package using creds from my dev_kp environment
$ dbt run --select gitlab 

# done (optimistically)
$ exit
> back in parent project context

# finally, lets update my hub DAG in Meltano Project (doesn't exist yet - see [#2920](https://gitlab.com/meltano/meltano/-/issues/2920))
$ nano meltano.yml
> ...
dags:
  meltano_hub:
    interval: @daily
    steps:
      - name: gitlab
        cmd: 'meltano elt tap-gitlab target-postgres --job_id=gitlab-to-postgres'
        retries: 2
      - name: google_analytics
        cmd: 'meltano elt tap-google-analytics target-postgres --job_id=google-analytics-to-postgres'
      - name: product_mart
        cmd: 'meltano invoke dbt run --select models/marts/product'
        depends_on:
          - gitlab
          - google_analytics
...

# wonder if the new DAG actually works?
# start a terminal session in the Airflow context
$ meltano shell airflow --environment=dev_kp
# Note: this could launch a local instance of `airflow webserver`
# for developer convenience 🤔

$ airflow dags list
> meltano_hub

$ airflow dags trigger meltano_hub
> runs DAG locally using config specified in dev_kp environment

# *goes and checks the Airflow UI on http://localhost:8080 and the test warehouse for data*

# done
$ exit

# lets see what the team thinks
$ git commit -am "added gitlab integration"
$ git push
$ glab mr create
# off it goes to CI ✉️

# profit ☕️
```

### What does success look like, and how can we measure that?

Users can work productively in a plugins context facilitated (and not obstructed) by Meltano Project. New users to a Project do not need to worry about the mechanics of installation and configuration; onboarding to an existing Project is as easy as `git clone` and `meltano shell <plugin name>` 🚀

### Regression test
(Ensure the feature doesn't cause any regressions)
- [ ] Write adequate test cases and submit test results
- [ ] Test results should be reviewed by a person from the team

### Links / references

- [#2920](https://gitlab.com/meltano/meltano/-/issues/2920) Meltano should output a DAG-like data structure with individual pipeline components
- [&82](https://gitlab.com/groups/meltano/-/epics/82) Improved dbt integration
- [#2210](https://gitlab.com/meltano/meltano/-/issues/2205) Add `docker_image` property to support non-Python/pip plugins

_Please note that this was taken from GitLab, to be changed accordingly_

## Option: Alternative framing around `meltano environment activate ...`

We should consider also if this could be an environment-level invocation, such as `meltano environment activate`. Which would be a much more robust version of sourcing the `.env` variables, but able to step into a context where all invocations are already contextualized and able to be invoked directly.

If an environment-level action, we get around issues of having to step separately into dbt and sqlfluff context separately, because all of the context for both would be set at time of activating the environment.

Story points: 12.0