Feature Request: Add support for Work Items
### Problem Statement
The GitLab Go package currently lacks high-level API support for work items, which are GitLab's collective term for epics, issues, and tasks. While issues have comprehensive support through the `IssuesService`, and epics were previously supported via REST API (now deprecated), there's no convenient way to interact with the work items GraphQL API.
Currently, developers must use `GraphQL.Do()` to issue arbitrary GraphQL queries, which creates significant friction:
1. **Query complexity**: Developers must learn GraphQL syntax and construct queries manually, which is a barrier to entry for those just trying to solve immediate business needs
2. **Data structure definition**: GraphQL responses require developers to define matching Go structs based on their specific queries
3. **Type conversions**: Response fields often need transformation (e.g., IID returned as string needs parsing to int64)
This offloads substantial complexity onto users that the library should reasonably handle.
### Proposed Solution
Create a new `WorkItemsService` with:
- **Pre-defined data structures** matching common work item fields and operations
- **High-level functions** (e.g., `GetWorkItem()`, `ListWorkItems()`, `CreateWorkItem()`, `UpdateWorkItem()`) that abstract away GraphQL query construction
- **Automatic type conversion** from GraphQL response types to idiomatic Go types
- **Consistent API patterns** following the conventions established by `IssuesService` and other existing services
The service would internally use GraphQL queries but expose a clean, REST-like interface that Go developers expect from this package.
### Context
- The REST API for epics is deprecated in favor of the work items GraphQL API
- Tasks currently have no high-level API support
- Work items represent GitLab's unified approach to work tracking across epics, issues, and tasks
### Next Steps
I'm willing to implement this feature but would like alignment on the approach before investing time and effort. Happy to discuss API design, scope, and implementation details.
issue