Preview Feature: Support for Version 2 Bridge Design

- Introduction of Action with a new 'connector' concept

  - In the original Bridge v1 design, each connector was exclusively tied to a single bridge.
    This design prioritized error isolation and performance but posed challenges for users setting up multiple bridges to the same service.
    For instance, setting up 10 bridges to a single Kafka cluster required the same configuration to be repeated for each bridge.

  - The revamped Action design provides more flexibility and better scalability:
    - Users have the option to either share a connector across multiple bridges or retain it exclusively for one bridge, as in v1.
    - For the majority of data bridges, sharing a connector among too many bridges might lead to performance degradation but avoids
      overloading the external system with too many connections if the number of bridges is very high.
    - In some cases, specific data bridges always utilize dedicated connections, even when the connector is shared.
      Right now these are:
      - Kafka Producer
      - Azure Event Hub Producer

- Management of Connectors
  - Connectors can now be managed separately, bringing in more flexibility.
  - New API endpoints have been introduced under the `/connectors` path for connector management.
  - Actions can be managed via the `/actions` endpoint.

- Limitations in e5.3.1

  - Currently, only the Kafka and Azure Event Hub producer bridges have been upgraded to the action design.
  - The action feature is accessible through config files and HTTP APIs. However, it's not yet available on the dashboard UI.