QPdfLinkModel should inherit from QAbstractItemModel like QPdfBookmarkModel for consistency

Currently, there's an architectural inconsistency between QPdfLinkModel and QPdfBookmarkModel in how they expose similar types of document element data.

Current Implementation:

• QPdfBookmarkModel inherits from QAbstractItemModel, allowing natural presentation of bookmark data in multiple columns
• QPdfLinkModel inherits from QAbstractListModel, restricting it to a single-column presentation despite having similar multi-faceted data

The Issue:
Both models represent document elements (bookmarks and links) that have multiple properties which users typically want to view in a columnar format. However, their different base classes lead to inconsistent usage patterns:

• QPdfBookmarkModel naturally displays properties like Title, Level, Page, Location, and Zoom in columns
• QPdfLinkModel requires a wrapper model (QAbstractTableModel) to achieve the same with its Rectangle, Page, Location, Zoom, and URL properties

Current Workaround:
To display link properties in columns, developers must create a wrapper model:

1. Create a new QAbstractTableModel
2. Use QPdfLinkModel as a data source
3. Map the different roles to columns manually

Proposed Solution:
QPdfLinkModel should inherit from QAbstractItemModel like QPdfBookmarkModel does. This would:

1. Provide consistent API design across PDF document element models
2. Allow natural presentation of link properties in columns
3. Eliminate the need for wrapper models
4. Make the API more intuitive for developers

Example Use Case:
When showing all the properties of a PDF document structure, applications typically get both bookmarks and links in similar table/tree views. The current implementation forces different approaches for similar UI elements, complicating the code and creating inconsistent user experiences.

Impact:
This change would improve:

• API consistency
• Developer experience
• Code maintainability
• UI implementation flexibility

While this would be a breaking change for Qt 6, it would align better with the principle of least surprise and provide a more consistent API design.