Clarify @type, additionalType, and genre

[CAOShurong]

Summary

• clarify that @type carries Schema.org/RO-Crate structural types and may be an array
• direct external-vocabulary classifications to additionalType without prescribing an ontology
• define genre as a human-readable string rather than an alias for @type

This documents the field roles agreed in the discussion and matches the repository's current support for multiple @type values.

Closes #105.

Validation

• python -m pytest --tb=short -s (5 passed)
• sphinx-build -M html docs/source <build-dir> --fail-on-warning
• rendered SPECIFICATION.md with Markdown-It and verified the three reference links

[NicolasCARPi]

Thank you very much!

[SteffenBrinckmann]

Sorry for being late to the discussion, after the merge.

• I would suggest that we attach a version number to the specification and make changes only to that version that is work-in-process. Changing something as great as @type in the process, is in my point of view, difficult for people to align to.
• As far as I understood, genre was the old system that was supposed to be deprecated. For me it is difficult to distinguish uniquely what is human-digestible vs maschine-actionable.