Reuse parent plugin installation directory using `inherit_from` and matching `pip_url` (prevent venv duplication)

Original Description

<details><summary>Click to expand</summary>

When a plugin inherits from another, both get their packages installed into their own venvs at `.meltano/{type}s/{name}` (e.g. `.meltano/extractors/tap-gitlab` and `.meltano/extractors/tap-gitlab--inherited`), even though they could reuse the same package on-disk, which would speed up `meltano install` and reduce the installation footprint.

One way to accomplish this would be to have plugins that share a `pip_url` share an installation directory, by using `.meltano/{type}s/{pip_url}` as the path, with `pip_url` hashed or transformed to a valid directory name. The resulting dirnames are pretty unwieldy though, and this would make it much harder to find a given plugin's installation directory just by browsing the filesystem and looking for its name. Adding a command to print the path (https://gitlab.com/meltano/meltano/-/issues/2337) would help, but there's a cost.

Alternatively, we could have plugins fall back on their parent's installation dir if their `pip_url`s match, so that we'd only have `.meltano/extractors/tap-gitlab` until `tap-gitlab--inherited` changes its `pip_url` and gets a `.meltano/extractors/tap-gitlab--inherited`. Note that the directory names should always correspond to plugins _in the project_, so that names are known to be unique and map 1:1 to `pip_url`s. Plugins inheriting directly from a discoverable plugin (e.g. `tap-postgres--db-one` and `tap-postgres--db-two` both inheriting from `tap-postgres`, without a plugin by that name existing in the project) would not use their parent plugin's name for the installation directory, since the name could refer to multiple variants with their own `pip_url`s.

This approach is consistent with the current behavior, where plugin dir names match project plugin names, with the addition of inheritance (unless `pip_url` is overridden). I think the limitation that it doesn't apply to plugins that don't share a common ancestor in the project, but do share a `pip_url`, is acceptable.

</details>

## Updated Summary (2022-03-03)

There are a few paths forward on this which each have their own pros/cons.

There are also a couple related issues that make the matter overall more complex:

- #3068+
- #2701+ 

## Simplest solution, using `inherits_from`

The simplest solution is to use the `inherits_from` option as a trigger for leveraging the same installation `venv_path` internally within Meltano. 

This rule would apply _only_ if the plugin inheriting from does not also define `pip_url`. If `pip_url` is also defined _and is different_, the `venv_path` for that plugin would be based only on its own name rather than its parent (meaing, a unique venv).

Pseudocode:

```py
    @property
    def venv_name(self) -> string:
        """Get the venv name this plugin should use."""
        if not self.inherits_from:
            # No parent. Use a unique venv per plugin.
            return self.plugin_name

        if not self.pip_url or self.inherits_from.pip_url == self.pip_url:
            # Use the parent's venv. Plugin is inheriting and there's no difference in pip_url.
            return self.parent.name

        # Default to unique venv per plugin.
        return self.plugin_name
```

Pros:

- It works automatically with users' existing project definitions.
- It speeds up the installation for most projects if they use `inherits_from` at least once in their project.

Cons:

- This would not solve for #3068 or #2701.
  - It doesn't solve for detecting changes in `pip_url`. (#2701)
  - It may or may not be able to solve for inheritance between plugins of different types, for instance: the scenario described in #3068 where it is desirable for `dbt` and `sqlfluff` to share a venv.
    - This is tricky because `inherits_from` was never imagined to solve for inheritance across a `transformer` plugin, for instance, and a `utility` plugin.
    - In theory, this too could be made to work, but even so, the other implications of `inherits_from` seem broader than would applicable to diverse utilities of fundamentally different functions and configuration options.
- It doesn't solve for reconciling plugin names with their venvs if a plugin is renamed within `meltano.yml`.
- It doesn't solve for `pip_url` which just _happen_ to be identical. (Not a common use case anyway.)


## Possible resolution strategy

In sequence, this might get us where we want to go:

1. Solve for the simplest `inherits_from` cases, as described above. This would probably solve for 90% of the venv duplication issues for an average project.
2. To solve for the "pip_url drift" issue described in #2701, leave a marker file within the venv page during installation with the text of `pip_url` text. Then check the pip_url against the marker file on each execution. If it differs from the current value of `pip_url`, raise a warning or error that prompts the user to reinstall.
3. To resolve complex venv sharing use cases described in #3068, expand the spec so that plugins can "inherit" or "share" _only_ the venv of another plugin, without having to inherit all the other types of functionality, such as config, commands, etc. (More details on alternatives are in #3608, and presumably those solutions would stack with the `inherits_from` and 'pip_url drift detection' in the above two issues.)

Story points: 8.0