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