Move SQS message queue to Amazon provider

The common.messaging abstraction should discover common messaging
queue providers using the same mechanism as we have for other core
extensions. Previously common.messaging had the optional (but not
really) dependencies to other providers, but that was not needed
and introduced unnecessary coupling.

By switching to our built-in discovery mechanism we get immediately
all the niceties of provider discovery mechanisms:

* queue is provided by the actual provider where the service or
  integration already is implemented (sqs -> amazon provider, in
  the future kafka -> kafka provider)
* queues are discovered from installed providers
* there is no coupling or imports between common.messaging and the
  providers that implement messaging, the dependency is in the other
  way - providers that implement messaging depend on common.messaging
* airflow providers queues CLI and providers core extensions
  documentation is automatically generated

Author: potiuk

airflow-core/docs/authoring-and-scheduling/connections.rst

@@ -47,5 +47,5 @@ Airflow allows to define custom connection types. This is what is described in d
 :doc:`apache-airflow-providers:index` - providers give you the capability of defining your own connections.
 The connection customization can be done by any provider, but also
 many of the providers managed by the community define custom connection types.
-The full list of all providers delivered by ``Apache Airflow community managed providers`` can be found in
+The full list of all connections delivered by ``Apache Airflow community managed providers`` can be found in
 :doc:`apache-airflow-providers:core-extensions/connections`.

airflow-core/docs/core-concepts/index.rst

@@ -43,6 +43,7 @@ Here you can find detailed documentation about each one of the core concepts of
     auth-manager/index
     objectstorage
     backfill
+    message-queues
 
 **Communication**