Make dynamically created resources configurable

**Problem**
Most of the resources created dynamically are not configurable. For instance see how the [PingSource receive adapter](https://github.com/knative/eventing/blob/master/pkg/reconciler/pingsource/resources/mt_receive_adapter.go#L49) is created.

**[Persona:](https://github.com/knative/eventing/blob/master/docs/personas.md)**
Which persona is this feature for?
Operator

**Exit Criteria**
A measurable (binary) test that would indicate that the problem has been resolved.
Receive adapter deployment or ksvc with extensions

**Time Estimate (optional):**
How many developer-days do you think this may take to resolve?
2-3

**Additional context (optional)**

The current solution relies on both `DeepDerivative` and an external way to dynamically patch resources. That's less than ideal. Not all controllers are using `DeepDerivative` (is this a bug?) and not all fields can be updated dynamically. Also what is "the external way"? We certainly need something more self-contained.

Another solution is to do what the alt Kafka channel implementation is doing: using [env vars](https://github.com/knative-sandbox/eventing-kafka/blob/92b3fc674c941409e716f1f4c62dbfd9a33578d8/config/400-deployment.yaml) (and soon [ConfigMap](https://github.com/knative-sandbox/eventing-kafka/blob/d7cd8aa44bd9adc6c0ddafaf0c1e04e9ba2ff0c8/config/200-eventing-kafka-configmap.yaml)) to specify the configuration parameters. The major (IMO) drawback of this solution is 1) it is not generic 2) there is always the risk of forgetting something. For instance there is no way to add `affinity` rules in there without modifying the code.

A third solution is specify the expected deployment or ksvc in a config map, similar to what we already do with the [default channel template](https://github.com/knative/eventing/blob/master/config/core/configmaps/default-broker-channel.yaml).

For instance `config-eventing.yaml` could have the following configuration:

```
apiVersion: v1
kind: ConfigMap
metadata:
name: config-eventing
namespace: knative-eventing
data:
mt-pingsource-adapter: |
apiVersion: apps/v1
kind: Deployment
metadata:
name: pingsource-mt-adapter
spec:
template:
spec:
containers:
- name: dispatcher
resources:
limits:
cpu: "1"
memory: 2Gi
requests:
cpu: 125m
memory: 64Mi
```

The eventing webhook must first validate the specified fields that are under its control (e.g. `apiVersion`, `kind`, `name`, `namespace`, `spec.template.spec.containers[0].name`). If `image` is specified, the webhook should reject the configmap.

The eventing controller would then augment the resource with the fields it "owns", like `serviceAccountName`, `image`, and so on.

The exact behavior is yet to be defined. I'm also planning to create a feature track document.

Comments? @cr22rc @n3wscott @eric-sap @travis-minke-sap @vaikas @grantr