Add jira --map-issue option

[kkaarreell]

Adds jira --map-issue option that enables user to map id from the issue-config file to an existing Jira issue.
For example:

newa jira --map-issue jira_epic=RHEL-12345 ...

[kkaarreell]

Semantic diff link https://app.semanticdiff.com/gh/RedHatQE/newa/pull/117/changes#newa/__init__.py?ignore_comments=false

[ep69]

I gave it try and it works.

What I'm not 100% sure about is how to behave when the specified mapping is wrong (user mistake):

$ snewa event --erratum 140235 jira --issue-config newa/jira.yaml --map-issue jira_task=CRYPTO-15442
11/05/2024 11:15:12 AM Using --state-dir=/var/tmp/newa/run-12
[2024-11-05 11:15:15,061] [event   ] Erratum release RHEL-10.0.GA transformed to a compose RHEL-10.0-Nightly
[2024-11-05 11:15:15,066] [event   ] Artifact job E: 140235 @ RHEL-10.0.GA written to /var/tmp/newa/run-12/event-140235-RHEL-10.0.GA.yaml
[2024-11-05 11:15:15,069] [jira    ] Discovered erratum job E: 140235 @ RHEL-10.0.GA in /var/tmp/newa/run-12/event-140235-RHEL-10.0.GA.yaml
[2024-11-05 11:15:16,020] [jira    ] Initialized Jira handler
[2024-11-05 11:15:16,020] [jira    ] Processing task_errata
[2024-11-05 11:15:20,014] [jira    ] New issue CRYPTO-15463 created

Config newa/jira/yaml contains:

project: CRYPTO
transitions:
  closed:
    - Closed.Done-Errata
  dropped:
    - Closed.Obsolete

issues:
 - summary: "Errata update - RHEL rhel-10.0 libfido2 - ER#{{ ERRATUM.id }} (r{{ ERRATUM.respin_count }})"
   description: "{{ ERRATUM.url }}\n{{ ERRATUM.components|join(' ') }}"
   assignee: '{{ ERRATUM.people_assigned_to }}'
   type: task
   id: task_errata
   on_respin: keep

User mistake is specifying jira_task on CLI vs. task_errata in config. In such a case, exit with an error might be more appropriate than creating and issue user needs to delete manually.

[The-Mule]

Code-wise it looks good to me. Some user-error handling can be always added later if needed.

[kkaarreell]

Code-wise it looks good to me. Some user-error handling can be always added later if needed.

Good point, I will address this in another MR.

[kkaarreell]

Code-wise it looks good to me. Some user-error handling can be always added later if needed.

Good point, I will address this in another MR.

#118