Discuss: what to call "inline transformers" aka "stream maps" aka "map transforms"

In preparation for #2299 (and/or the similar #2300), we should discuss what to call these things. We especially should consider how the naming decisions will impact (1) the new user experience and (2) possibly overlap or confusion regarding other existing plugins and interactions.

## Background Context

### History of "Stream Maps" naming within the SDK

When developing the Stream Maps feature in the SDK, one very important paradigm which allowed that effort to move forward was the concept of the "Map" process of a "Map-Reduce" paradigm. While the word "tranformation" can mean anything in the set of operations {Map/Reduce/Lookup/Filter/etc.}, we are limited in an inline capacity to basically these two: Map and Filter. (Lookups are possible in an inline capacity but they are very different than lookups which occur in SQL, and as such they are extremely expensive and require a robust caching strategy that is far beyond our scope.)

So, "Stream Maps" naming or "Map Transforms" naming was intended to highlight the focus on operations which can be performed scalably in an _inline_ capacity. **Unlike "true" transform tools like dbt, we do not have all of the data available before we execute; we have only one record at a time and we must be able to treat each record in isolation before passing it downstream (or not).**

Legacy ETL tools tried to do any and all type of "big T" transform functions `{Map/Reduce/Lookup/Filter/etc.}` before passing data downstream to the target, which although more rare now is still a problem in the industry using existing tools like Informatica, SSIS, Alteryx, Azure Data Factory, etc. This "traditional/legacy ETL" approach is an anti-pattern for very good reason and we should be very clear we are _not_ supporting it.

### Why not just call them "transformations" or "transforms"

If applying a little "m" for a lightweight inline map transform, `ELT` becomes `EmLT`. Note the little `m` and the big `T` are entirely different capabilities, with different performance constraints and resource availability. We _do not_ want to confuse users by saying this is okay: `ETLT` - this would be a huge step backwards in terms of DataOps best practices, and would cause detrimental confusion to end users if they think there's no difference between "transform" in the middle of EL and the "transform" in the SQL/dbt layer.

When we speak of these conversationally, we use the word "transformations" often. However, the name collision with dbt (the *true* "T" in "ELT" pipeline, is extremely problematic - the `m` and `T` perform very different functions, with different physics constraints, latency expectations, and host server hardware profiles. They also have very different risk profiles for data loss in case of code errors or other unexpected failure.

## Option A: `mappers` are a new plugin type, with associated `mappings` entries in `meltano.yml`

Similar to as written up in #2299:

```shell
meltano add mapper meltano-map-transform
meltano add mapper pipelinewise-transform-field
```

```yml
# meltano.yml
mappers:
- name: meltano-map-transform
  pip_url: meltano-map-transform
  config:                         # Optionally, a default config.
    # ...
- name: pipelinewise-transform-field
  pip_url: pipelinewise-transform-field
extractors:
- name: tap-gitlab
  # ...
  mappings:
  - name: pii-hasher               # The name of the map transform to apply.
    mapper: meltano-map-transform  # The mapper plugin to use.
    config:                        # What will be sent to the transformer in a config.json file.
      stream_maps:
        customers:
          id_hashed: md5(record['id'])
          id: None
```

Option B: Transformers are of a `type`: `streaming` or `build`

Another (admittedly less preferred) option would be to allow `mappers` into the family of `transformer` utilities but with the addition of a new `type` attribute which specifically distinguishes them from other transformation types.

The `dbt` transformer would be something to indicate it has all data landed in the target upfront, such as `build` or `post-load`.

The `mapper` transformers would have some `type` value indicating their place as map-transforms and not full fledge data build/transform/aggregation tools. Possible values for `type` could be: `streaming`, `inline`, `mapper`, or `stream_map`.

cc @tayloramurphy, @edgarrmondragon, @pandemicsyn, @kgpayne

Story points: 4.0