Make the JIRA link template configurable via `wildfly-bot.yml`

Follow-up from #238.

The JIRA link template used by the bot to generate "Additional WildFly Issue Links Found..." sections in PR descriptions is currently hardcoded in RuntimeConstants.java:

public static final String BOT_JIRA_LINK_TEMPLATE = "https://redhat.atlassian.net/browse/%1$s";

If the JIRA domain changes again (as it did from https://issues.redhat.com -> https://redhat.atlassian.net), a code change + redeployment is required. This should instead be configurable via wildfly-bot.yml config file (no redeployment would be necessary), with a sensible default fallback (?).

So we would have something like:

wildfly:
  projectKey: "WFLY" # optional (?), and should probably be project_key (snake case)
  issueTrackerLink: "https://redhat.atlassian.net/browse" # new and optional (?), and should probably be issue_tracker_link (snake case)
  # ...

One note: I am not 100% sure how I feel about these two options being optional. Would it not be better to make these fields explicit, so that these behavior features are not so dependent on the wildfly-github-bot project rather than the actual wildfly-bot.yaml config file?

Another thing we might consider is whether including an "issue tracker link" would make the current simple nature of coarse grain too complicated--since all WILDFLY-related repos are expected* to be part of the same JIRA domain, the current BOT_JIRA_LINK_TEMPLATE has one advantage in this regard. However, I think the above notes could outweigh this advantage.

*) Not to be too pedantic, but in theory, the opposite could still happen (two (or more) WF/EAP related projects with different JIRA domains).

Start with RuntimeConstants.java and trace how BOT_JIRA_LINK_TEMPLATE is used when generating the "Additional WildFly Issue Links Found..." section in pull request descriptions. Then inspect the wildfly-bot.yml configuration handling to determine where an optional issue-tracker link and fallback belong. Done means the link template can be configured without redeployment while retaining a sensible default.