First-class dependency graph for Issues and Pull Requests

### What problem would this solve? Gitea currently has several concepts that express relationships between issues and pull requests: * references (`#123`, `owner/repo#123`) * issue dependencies * pull requests targeting other branches (which can be used to form stacked PR workflows) However, there does not appear to be a single, first-class graph describing dependencies between work items. As a result, higher-level workflows such as: * dependent pull requests * stacked pull requests * cross-repository pull request dependencies * dependency visualization * merge blocking based on prerequisites either cannot be implemented or require ad-hoc logic tied to specific workflows. ### What do you propose? Introduce a generic dependency model between Issues and Pull Requests. Conceptually: ```text WorkItem A ---> WorkItem B ``` meaning: > WorkItem A depends on WorkItem B. Since pull requests are already represented internally as issues with additional metadata, this could potentially be implemented as a generic dependency relation between issue records. Example schema (illustrative only): ```go type Dependency struct { ID int64 SourceID int64 TargetID int64 Type string } ``` or any equivalent representation. ## Desired properties * Works for Issue → Issue dependencies. * Works for Pull Request → Pull Request dependencies. * Works for Issue → Pull Request dependencies. * Works across repositories. * Exposed through REST and GraphQL APIs. * Queryable in both directions ("depends on" and "blocked by"). ## Potential applications The dependency graph could serve as a common foundation for: * stacked pull requests * cross-repository pull request dependencies * release coordination * package dependency workflows * merge gating * dependency visualization without requiring each feature to introduce its own relationship model. ## Benefits Creating a generic dependency layer first would allow future workflow features to build on a shared foundation rather than introducing multiple partially-overlapping mechanisms.