The class hierarchy around the (org.openjdk.skara.issuetracker.)Issue interface is weird and cumbersome to work with. This interface is representing an Issue as returned from an IssueTracker. It's implemented by `JiraIssue` (and `TestIssue` for testing purposes). It's also extended by `PullRequest`, which makes it awkward to add Jira/bug tracker specific functionality to it since we must then also implement that for all `PullRequest` implementations (usually by just throwing a runtime exception). It's rare to use `Issue` as something that can be either a `PullRequest` or an actual issue, so sharing this interface isn't adding much value.

In addition to this, there is also an unrelated class called Issue (org.openjdk.skara.vcs.openjdk.Issue) in the vcs module. This class just represents the OpenJDK interpretation of an issue in the context of a commit message. These classes are however used together sometimes, which is causing a lot of confusion.

I would like to improve this situation. My proposal is to introduce a new interface `IssueTrackerIssue` which is a sub type of `Issue` that contains methods specific to bug trackers (or at least Jira). In practice right now this is links and properties. The name reflects that this is the kind of issue returned from an `IssueTracker` as opposed to an Issue from any kind of `Forge`. Having that in an interface enables us to also define a specific test implementation `TestIssueTrackerIssue` that mimics our `JiraIssue` implementation without clashing with `PullRequest` and its implementations. With this new type name, we can also get around the clash when having to deal with the vcs Issue type. This solution retains the shared super interface `Issue` between `IssueTrackerIssue` and `PullRequest`.