Improve FailedScheduling Event wording when there is a volume conflict due to different Availability Zones

1. Proposed title of this feature request
Improve FailedScheduling Event wording when there is a volume conflict due to different Availability Zones

2. What is the nature and description of the request?
If a pod is running in a specific Availability Zone but has a Volume attached from a different Availability Zone (or even Volume from multiple Availability Zones), scheduling of the given pod fails with the below Event.

17s         Warning   FailedScheduling         pod/hostname-6789bfb487-7m5pf      0/6 nodes are available: 1 node(s) had volume node affinity conflict, 2 node(s) didn't match Pod's node affinity/selector, 3 node(s) had untolerated taint {node-role.kubernetes.io/master: }. preemption: 0/6 nodes are available: 6 Preemption is not helpful for scheduling.

While this Event might be clear for OpenShift Container Platform 4 - Site Reliability Engineer / DevOps Engineer, it may not be clear for Developers running on top of the platform.

Also, depending on whether resource requests may be set, additional information about CPU and Memory may be displayed. Which again is valid and useful for platform Teams. But developers may not be familiar enough with the terminology and thus appreciate a more strict/specific Event being reported to help understand what is causing the pod scheduling failure.

3. Why does the customer need this? (List the business requirements here)
As part of development experience and enablement, many non kubernetes aware development team is moving towards OpenShift Container Platform 4. While platform teams are able to ease that effort, running the application is usually the task of application specific teams (application operations or developers). Forcing them to understand everything in the kubernetes universe is probably not suitable, which is why pod scheduling failure events should be changed or improved to better support developer persona that are not familiar with kubernetes and thus help them understand where the problem is located respectively why the pod is failing to schedule.

For example, when also using volumes to persist the data the Event reported is rather cryptic and developers would rather appreciate an information that pod assignment and volume assigned does not match (different availability zone or similar) as the rest is at this state not of interest for them.

4. List any affected packages or components.
kubernetes scheduler