Service level minScale

## Problem statement:

Today, developers can pick a number of [minimum replicas](https://knative.dev/docs/serving/autoscaling/scale-bounds/), however:
- any update to this setting results in the full deployment of a new revision.
- it is a revision-level setting, meaning that if multiple revisions are serving traffic, the number of total min replicas depends on how many revisions are serving.

## Suggested feature

Introduce a new "minScale" annotation at the service level, which applies to all revisions of the service.

### Use cases

Allows to dynamically control the number of minimum replicas of a Knative *service*, which is useful when:

- anticipating an event that will result in a traffic spike and want to pre-warm replicas
- automating min replicas allocation (e.g. 0 during the night, N during the day)
- wanting to reserve some capacity for a service within the cluster

### API

```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: my-service
annotations:
autoscaling.knative.dev/minScale: '100'
spec:
template:
annotations:
autoscaling.knative.dev/minScale: '10'
spec:
container:
image: …
```

### Relationship with per-revision minScale

Min replicas are allocated first from Service-level minScale. Then, if the Revision-level minScale is higher than the allocated number, the revision gets the higher number of min replicas.

E.g. if Service-level specifies 20 min-replicas, and splits traffic at 50/50 between Revision A and Revision B. If Revision A specifies 15 minScale, then:

- Revision A gets 15
- Revision B gets 10

### Additional notes

Cloud Run, which aims at portability with Knative serving, is introducing this feature using a vendor extension. Cloud Run would switch to using the Knative spec if Knative defined and implemented this behavior.

/area API
/area autoscale
/kind spec