After merging this PR, check if https://issues.redhat.com/browse/OBSDOCS-1855 is a duplicate.

On installation page:

• replace minimal TempoStack and TempoMonolithic with multi-tenant deployment on installation page
• add new section for OTEL collector (mandatory for multi-tenant deployments)
• The OTEL deployment should include all recommended and required components - RED metrics, k8sattributes processor

Correctly defining multitenancy is a must for users wanting to deploy and make use of distributed tracing, both for the Jaeger UI and the new Tracing UI. That's why it's crucial to have a documentation that is as clear and helpful as possible. In this task, the following issues are proposed to be improved in this section (Tempo Multitenancy):

1. Clarify if the existing note still applies, and modify accordingly:

2. Let's add a small list or index of actions needed to properly define RBAC and tenants in Tempo before all the samples are presented, at the very beginning of the section. Today it's a bit unclear if all those samples are needed (and they are). On a personal note, unexperienced users may find this overwhelming. The list could look like this: (needs revision, this is just a proposal). A procedure instead of just a section, could be a great way of tackling this one as well.  "In order to properly define Tenants and give them proper read and write access, the distributed tracing stack, based on the Red Hat build of OpenTelemetry and Tempo, needs proper authorization configuration. Such configuration uses the ClusterRole and ClusterRoleBinding of the Kubernetes Role-Based Access Control (RBAC). By default, no users have read or write permissions. Traces can be read via the Jaeger UI or the OpenShift Tracing UI plugin. Traces can be written through an OpenTelemetry collector. The following needs to be configured:

1. 1. Reading traces 
      1. Define desired tenantName and tenantId in the Tempo custom resource
      2. Enable tenants to read traces by adding them to a ClusterRole and giving them read (get) permissions
      3. Grant authenticated users the read permissions for trace data by defining a ClusterRoleBinding to the previously defined role
   2. Writing Traces
      1. Create a ServiceAccount for the OpenTelemetry Collector
      2. Enable tenants to write traces by adding them to a ClusterRole and giving them create (write) permissions
      3. Grant the OpenTelemetry Collector write permissions for trace data by defining a ClusterRoleBinding to the previously defined role and attaching it to the ServiceAccount
      4. Configure the OpenTelemetry collector by:
         1. Adding the bearertokenauth extension and a valid token to the tracing pipeline service.
         2. Add the desired tenant in the otlp/otlphttp exporters as the "X-Scope-OrgID" headers
         3. Enable TLS with a valid certificate authority file.
2. tenantId's present in the Sample Tempo CR: are not very clear. Users may think that they need to generate some hex username without clear guidance. Let's clearly say what can be a tenant: (any string between double quotes? Others?)
3. Add TempoMonolithic multitenancy subsection (only the Tempo config would be needed, together with the already existing TempoStack). This action may be a duplicate of another ticket.  <-- Covered in TRACING-4649
4. Since Tenants are mandatory in order to make use of Tempo, it needs to be mentioned and referenced in the installing and configuring tempo sections. Otherwise, it seems like an optional feature. <-- Covered in TRACING-4649
5. Also, see discussion in slack. The message when accessing the root is path can be seen as an error. Documentation should advance this and explain that is normal