[Datadog] Add custom tag names for metric filters

[phalbert]

Description

This PR introduces a feature that allows clients to specify custom tag names for hosts, in addition to the default universal Datadog tags (env and service). This enhancement provides flexibility for clients who have hosts tagged with different tags than the default ones used by Datadog.

Description

The current system defaults to using the universal Datadog tags env and service for host identification and selection. However, some clients (e.g., IU) may have hosts tagged with different tags. To address this need, the following changes have been made:

• Modified the kind selector to allow the specification of custom tag names.
• Default behavior remains unchanged, using env and service tags if no custom tags are specified.
• Updated the datadogSelector configuration to include fields for specifying custom tags.

kind: serviceMetric
selector:
  query: "true"
  datadogSelector:
    metric: "avg:system.disk.used"
    env: 
      tag: "environment"  # Custom tag specified by the user
      values: "*"
    service: 
      tag: "servicename"  # Custom tag specified by the user
      values: "*"
    timeframe: 5

Additional Notes

• Backward Compatibility: The implementation ensures backward compatibility with existing configurations that use only the default env and service tags.
• Documentation: Updated documentation and examples have been provided to guide users on how to specify custom tags in their configurations.

Type of change

Please leave one option from the following and delete the rest:

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

All tests should be run against the port production environment(using a testing org).

Core testing checklist

• Integration able to create all default resources from scratch
• Resync finishes successfully
• Resync able to create entities
• Resync able to update entities
• Resync able to detect and delete entities
• Scheduled resync able to abort existing resync and start a new one
• Tested with at least 2 integrations from scratch
• Tested with Kafka and Polling event listeners

Integration testing checklist

• Integration able to create all default resources from scratch
• Resync able to create entities
• Resync able to update entities
• Resync able to detect and delete entities
• Resync finishes successfully
• If new resource kind is added or updated in the integration, add example raw data, mapping and expected result to the examples folder in the integration directory.
• If resource kind is updated, run the integration with the example data and check if the expected result is achieved
• If new resource kind is added or updated, validate that live-events for that resource are working as expected
• Docs PR link here

Preflight checklist

• Handled rate limiting
• Handled pagination
• Implemented the code in async
• Support Multi account

Screenshots

Include screenshots from your environment showing how the resources of the integration will look.

API Documentation

Provide links to the API documentation used for this integration.

[Tankilevitch]

LGTM