CollectionItem refactoring

Opening this issue to document a project I would like to tackle soon: refactoring the code to introduce an abstract CollectionItem class.

## Current state

Our XML files (called Collections internally) store a variety of items that can be linked to people:

- Volumes, which have Anthology IDs
- Papers, which have Anthology IDs
- Talks, which don’t currently have IDs

Some of the consequences of how we currently handle this are:

- Talks are "second-class citizens" in that they don’t have IDs, creating challenges for displaying them on the website (#5612)
- Only Papers get displayed on author pages, and it creates overhead to generalize this to other contribution types (e.g. volumes without frontmatter, #7973)
- There’s currently no way to represent items that don’t fit into one of these predefined categories, e.g. podcasts (#497)
- In Python scripts, typing is tricky as functions may return e.g. `Volume | Paper | Talk`, which have different attributes and do not inherit from a common parent class.

## Proposal

I want to introduce a CollectionItem class that serves as the base class for anything that

- Can be represented in a Collection (i.e. an XML data file)
- Can be referred to by a unique ID
- Can have NameSpecifications attached to it linking it to people

This would mean that

- Volumes, Papers, Talks all inherit from CollectionItem
- Frontmatter will become a separate type from Paper, as they function slightly differently, allow only a subset of fields, and need a lot of special handling in the current Paper class
- There will be a common interface (as defined by CollectionItem) for all item types, reducing the need to handle each one seperately in e.g. build scripts
- New types of contributions (e.g. podcasts) can more easily be added in the future by creating a new class that inherits from CollectionItem

Start by reviewing the existing Volume, Paper, and Talk representations and how Collection XML data is consumed by the Python and build scripts. Map the shared identity and NameSpecifications requirements, then confirm that the proposed CollectionItem hierarchy, separate Frontmatter type, and future contribution types are supported consistently across those uses.

由索引模型根据 Issue 内容生成。