docs: overall minor renovations (#1874)

* docs: simplify README.md and make index.md to refer to it
* docs: change order for pages in navigation and add missing pages
* docs: fix headings to improve navigation, transform notes to admonition, fix indentation, linting issues and minor issues
* docs: merge docs for using images from private registries
* docs: add example to integrate LDAP configuration via extra_settings_files
* Apply suggestions from code review
docs: apply suggested changes

Co-authored-by: Don Naro <dnaro@redhat.com>

* docs: update the doc site url as same as the url in https://www.ansible.com/ecosystem/
* docs: minor fixes for hpa page
* docs: expand note block
* docs: apply #1904 to README.md

---------

Co-authored-by: Don Naro <dnaro@redhat.com>

docs/migration/migration.md

@@ -19,7 +19,8 @@ stringData:
 type: Opaque
 ```
 
-**Note**: `<resourcename>` must match the `name` of the AWX object you are creating. In our example below, it is `awx`.
+!!! note
+    `<resourcename>` must match the `name` of the AWX object you are creating. In our example below, it is `awx`.
 
 ### Old Database Credentials
 
@@ -41,16 +42,14 @@ stringData:
 type: Opaque
 ```
 
-> For `host`, a URL resolvable by the cluster could look something like `postgresql.<namespace>.svc.<cluster domain>`, where `<namespace>` is filled in with the namespace of the AWX deployment you are migrating data from, and `<cluster domain>` is filled in with the internal kubernretes cluster domain (In most cases it's `cluster.local`).
+!!! note
+    For `host`, a URL resolvable by the cluster could look something like `postgresql.<namespace>.svc.<cluster domain>`, where `<namespace>` is filled in with the namespace of the AWX deployment you are migrating data from, and `<cluster domain>` is filled in with the internal kubernetes cluster domain (In most cases it's `cluster.local`).
 
-If your AWX deployment is already using an external database server or its database is otherwise not managed
-by the AWX deployment, you can instead create the same secret as above but omit the `-old-` from the `name`.
-In the next section pass it in through `postgres_configuration_secret` instead, omitting the `_old_`
-from the key and ensuring the value matches the name of the secret. This will make AWX pick up on the existing
-database and apply any pending migrations. It is strongly recommended to backup your database beforehand.
+If your AWX deployment is already using an external database server or its database is otherwise not managed by the AWX deployment, you can instead create the same secret as above but omit the `-old-` from the `name`.
+In the next section pass it in through `postgres_configuration_secret` instead, omitting the `_old_` from the key and ensuring the value matches the name of the secret. This will make AWX pick up on the existing database and apply any pending migrations.
+It is strongly recommended to backup your database beforehand.
 
-The postgresql pod for the old deployment is used when streaming data to the new postgresql pod.  If your postgresql pod has a custom label,
-you can pass that via the `postgres_label_selector` variable to make sure the postgresql pod can be found.
+The postgresql pod for the old deployment is used when streaming data to the new postgresql pod.  If your postgresql pod has a custom label, you can pass that via the `postgres_label_selector` variable to make sure the postgresql pod can be found.
 
 ## Deploy AWX
 
@@ -66,7 +65,9 @@ spec:
   secret_key_secret: <resourcename>-secret-key
   ...
 ```
+
 ## Important Note
+
 If you intend to put all the above in one file, make sure to separate each block with three dashes like so:
 
 ```yaml
@@ -79,4 +80,5 @@ If you intend to put all the above in one file, make sure to separate each block
 ---
 # AWX Config
 ```
+
 Failing to do so will lead to an inoperable setup.