Restored existing content in new format: Fixes #1638 

Observation: there are no requirements for ephemeral and persistent storage

Co-authored-by: Gergely Csatari <gergely.csatari@nokia.com>

Co-authored-by: Gergely Csatari <gergely.csatari@nokia.com>

Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>

Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>

Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>

Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>

Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>

Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>

Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com>

$.6 Storage components, `ra2.stg.004' added link to RA2 2.3 Requirement req.inf.stg.01

Delete content that belongs to RA Chapter 3:

- from ra2.stg.001: "Ephemeral storage exists for the life of a container.<br>Kubernetes Volumes attached using a Volume plugin can also be used to deliver Ephemeral Storage (may require additional tasks to ensure deletion of ephemeral storage on the shutting down of a container)" 

- from from ra2.stg.002: "This additional storage, that is attached to a container using a Kubernetes Volume, does not live and die with the container but instead follows the lifecycle of the Pod that the container is a part of. " 

- from ra2.stg.005: "The implementation may utilise either an In-tree or Out-of-tree type of Volume plugin.<br>In-tree plugins are built, linked, compiled and shipped with the core Kubernetes binaries and, thus, require the core Kubernetes code to be changed whenever a new backend storage system needs to be supported.<br>Out-of-tree plugins allow new backend storage systems to be supported without any changes to the core Kubernetes code." 

- from ra2.stg.007: "Storage Classes allow a consumer of the Kubernetes platform to request Persistent Storage using a Persistent Volume Claim and for a Persistent Volume to be dynamically created based on the "class" that has been requested. This avoids having to grant `create`/`update`/`delete` permissions in RBAC to PersistentVolume resources, which are cluster-scoped rather than namespace-scoped (meaning an identity can manage all PVs or none)."