[🐛 Bug]: Jira providers ignore ticket_creation_url and link tickets by the connection host

[purisev]

Describe the bug

Both Jira providers declare ticket_creation_url in their authentication config
(keep/providers/jira_provider/jira_provider.py:53,
keep/providers/jiraonprem_provider/jiraonprem_provider.py:43) and neither one
reads it. That declaration is the only place the name appears in either file.

The link Keep hands back is built from the host the provider connects to
(jira_provider.py:599 and :629, jiraonprem_provider.py:557 and :580):

result["ticket_url"] = f"{self.jira_host}/browse/{issue_key}"

Those two addresses are not always the same. Jira can sit behind a reverse proxy
under another hostname, or Keep can reach it over a cluster-internal address that
resolves nowhere else. Workflows put ticket_url on the alert through
enrich_alert, so an address only Keep can reach then shows up in the UI and in
every notification built from that alert.

To Reproduce

1. Configure the provider with host set to an internal address, say
   http://jira.internal:8080, and ticket_creation_url set to
   https://jira.company.com/secure/CreateIssue.jspa.
2. Run a workflow that creates or updates a ticket.
3. ticket_url comes back as http://jira.internal:8080/browse/KEY, which
   nobody outside the cluster can open.

Expected behavior

ticket_creation_url holds the public address, so the returned links use it as
their base. The field points at the new-issue form, and Jira writes that link in
several ways, so all of these should work: /secure/CreateIssue.jspa,
/secure/CreateIssue!default.jspa?pid=10000&issuetype=1, either of them under a
context path, and a plain base URL with or without a scheme. An empty field
leaves today's behaviour in place.

Additional context

A PR implementing this follows.