No indication of an error bubbled up to the ksvc

Once deployed, and after scaled down to zero, if there's an error scaling back up then it appears that there's no error message shown to the user in the ksvc. Here's a sample flow:

- create a ksvc - image: duglin/bug - everything comes up ok
- let things scale down to zero
- delete duglin/bug
- curl the app and I get this:
```
$ curl -v http://bug-default.kndev2-78a07a02fd786bfb6bcc17ab72c5a19d-0000.us-south.containers.appdomain.cloud
* Rebuilt URL to: http://bug-default.kndev2-78a07a02fd786bfb6bcc17ab72c5a19d-0000.us-south.containers.appdomain.cloud/
* Trying 169.48.95.69...
* TCP_NODELAY set
* Connected to bug-default.kndev2-78a07a02fd786bfb6bcc17ab72c5a19d-0000.us-south.containers.appdomain.cloud (169.48.95.69) port 80 (#0)
> GET / HTTP/1.1
> Host: bug-default.kndev2-78a07a02fd786bfb6bcc17ab72c5a19d-0000.us-south.containers.appdomain.cloud
> User-Agent: curl/7.58.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host bug-default.kndev2-78a07a02fd786bfb6bcc17ab72c5a19d-0000.us-south.containers.appdomain.cloud left intact
curl: (52) Empty reply from server
```
I look at the status of the ksvc and I see:
```
status:
address:
url: http://bug.default.svc.cluster.local
conditions:
- lastTransitionTime: "2021-07-24T13:38:15Z"
status: "True"
type: ConfigurationsReady
- lastTransitionTime: "2021-07-24T13:38:16Z"
status: "True"
type: Ready
- lastTransitionTime: "2021-07-24T13:38:16Z"
status: "True"
type: RoutesReady
```
- Notice no indication that things are busted
- check the revision:
```
status:
actualReplicas: 0
conditions:
- lastTransitionTime: "2021-07-24T13:39:59Z"
message: Requests to the target are being buffered as resources are provisioned.
reason: Queued
severity: Info
status: Unknown
type: Active
- lastTransitionTime: "2021-07-24T13:38:15Z"
status: "True"
type: ContainerHealthy
- lastTransitionTime: "2021-07-24T13:38:15Z"
status: "True"
type: Ready
- lastTransitionTime: "2021-07-24T13:38:15Z"
status: "True"
type: ResourcesAvailable
```
The "Active" condition does seem to give a hint, but I'm not sure a normal user would know that that means - nor is it clear that there's anything wrong. Instead it sounds like things are just in a "queued" state.

Should we have bubbled up the error message from the pod (about not being able to pull the image) all the way to the ksvc so the user can see it w/o having to drop down into Kube resources?

Reproduce the scale-to-zero flow described in the issue, then compare the ksvc and revision status conditions when the image can no longer be pulled. Trace how the pod error and revision Active condition are exposed at the ksvc level; done means the user-visible ksvc status clearly indicates the scale-up failure.

Written by the indexing model from the issue text.