Add Jira integration

[santihernandezc]

This PR introduces support for JIRA integration in Grafana Managed Alertmanager.
It's almost carbon copy of the prometheus/alertmanager#3590 (credits to @jkroepke) with couple changes:

• b52aeaa (#280) Configuration extended with option dedup_key_field that allows to specify a custom field to store deduplication key. The field must be a text field. If it is not specified, the deduplication key is added to labels.
• 1578f74 (#280) changes how description is handled in v3 API:
  • if the payload is not a valid JSON it treats it as string, truncates it and created and ADF document
  • if payload is a valid JSON, it does not truncate it and puts into the body as is. The code in the upstream PR would fail to parse truncated JSON. This way it will be on API to reject it as too long.
• d9b37ab (#280) changes how empty transition settings are treated. In contrast to the upstream implementation that looks for empty-string transition and fails notification, this integration skips resolving\reopening of integration.
• to match the behavior of other integrations, errors in expanding template do not cause the integration to fail. Instead, it follows the Grafana's paradigm of best effort to notify user even if the payload is not what user expects and falls back to the default templates.
• handling of field Fields.
  • The original PR does conversion of map[any]any to map[string]any here because yaml unmarshaller produced result that is not supported by json marshaller. In the case of Grafana the integration configuration is stored in JSON and therefore, it is not affected by this problem.
  • However, due to limitations put by Grafana's UI framework for integrations, the Fields could be only a map[string]string. To workaround this limitation the config parser is extended to scan values and parse if string is a valid JSON

How integration works

Diagram

Notes for reviewer

Due to some security reason, the Grafana's webhook sender does not support GET requests. I initiated extraction of it in #281 to alerting module to be able to change it and have more control over its behavior. In the meantime, I worked around GET requests 449c192 (#280). I will remove once the migrated sender will be able to process GET requests.

[jkroepke]

Some changes are great. I hope
Some of them can be done upstream

[santihernandezc]

Looks good!
I left a few comments. Also, please consider capitalizing log lines.