Remove csi volume sources from proposal

CSI volume sources introduce a host of concerns that greatly expand the
scope of this EP. The build controller uses the privileged security
context constraint, which allows build pods to bypass most security
features in OpenShift. Therefore, volume mounts in build pods need to
be tightly controlled. CSI volume types are by their nature open-ended,
and could be an attack vector if a developer uses an insecure CSI driver
implementation. The proposal has been updated to establish graduation
criteria for adding new volume source types to builds, including
security, testing, lifecycle concerns, failure modes, and feature
gating.

This update also adds definitions to clarify what is meant by a volume
mount. To distinguish Kubernetes volumes+mounts from buildah's volume
mount mechanism, the terms "volume content," "input
volume," "buildah volume mount," and  "buildah runtime environment" were
introduced. The proposed API uses these terms to distinguish build
volume mounts from pod volume mounts. Documentation requirements for
this feature were added in the "Drawbacks" section of the proposal.