### Apache Airflow Provider(s)

pagerduty

### Versions of Apache Airflow Providers

apache-airflow-providers-pagerduty==2.0.1

### Apache Airflow version

2.1.4 (latest released)

### Operating System

macOS catalina

### Deployment

Virtualenv installation

### Deployment details

_No response_

### What happened

Currently, the PagerdutyHook can be used to access two API's: 
- Events API: interface to send alerts. Needs only  a integration key/routing key/Events API key. (https://developer.pagerduty.com/docs/get-started/getting-started/#events-api)
- Pagerduty API: interface to interact with account data, project setup, etc. Needs only a Pagerduty rest API Key or account token. (https://developer.pagerduty.com/docs/get-started/getting-started/#rest-api)

In order to interact with the API's, the PagerdutyHook uses two attributes that refer to these api keys: 
- `token`:  Refers to the account token/rest API key. This attribute is retrieved from the `Password` field in the connection or can be set at initialization of a class instance by passing it into the init method of the class.  In the __Init__ method, its value is asserted to be not `None`. The token is **not used** for sending alerts to Pagerduty.
- `routing_key`: Refers to the integration key/Events API key. This attribute is retrieved from the `Extra` field and is used in the `create_event` method to send request to the Events API. In the `create_event` method the value is asserted to be not `None`.

As a result if users want to use the hook to only send events, they will need to provide a connection with a random string as a password (which can't be None) and the actual integration key in the `extra` field. This to me makes no sense. 

**Proposed solution:** Rather than having the two api's in a single hook, separate them into two different hooks. This increases code simplicity and maintainability.

### What you expected to happen

_No response_

### How to reproduce

_No response_

### Anything else

_No response_

### Are you willing to submit PR?

- [X] Yes I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

airflow/providers/pagerduty/hooks/pagerduty.py
custom_details: Optional[Any] = None,
        group: Optional[str] = None,
        component: Optional[str] = None,
        class_type: Optional[str] = None,
        images: Optional[List[Any]] = None,
        links: Optional[List[Any]] = None,
    ) -> Dict:
        """
        Create event for service integration.
        :param summary: Summary for the event
        :type summary: str
        :param severity: Severity for the event, needs to be one of: info, warning, error, critical
        :type severity: str
        :param source: Specific human-readable unique identifier, such as a
            hostname, for the system having the problem.
        :type source: str
        :param action: Event action, needs to be one of: trigger, acknowledge,
            resolve. Default to trigger if not specified.
        :type action: str
        :param routing_key: Integration key. If not specified, will try to read
            from connection's extra json blob.
        :type routing_key: str
        :param dedup_key: A string which identifies the alert triggered for the given event.
            Required for the actions acknowledge and resolve.
        :type dedup_key: str
        :param custom_details: Free-form details from the event. Can be a dictionary or a string.
            If a dictionary is passed it will show up in PagerDuty as a table.
        :type custom_details: dict or str
        :param group: A cluster or grouping of sources. For example, sources
            “prod-datapipe-02” and “prod-datapipe-03” might both be part of “prod-datapipe”