Classical music metadata support

[certuna]

Implements #275

Builds on Multiple artist support #2524 , ideally that one should get merged first.

Navidrome follows the is_classical and showmovement tags (used by Picard and Apple) to set if a mediafile should be treated as Classical.

For files that don't have these tags, there's a new option scanner.AutoDetectClassical = true/false which enables "auto-detect" if a track is Classical. The criteria are either/or:

• file has both composer AND movementname tags
• one of the genre tags is "Classical" (note: I don't 100% like this, since it's not language-neutral, but it's quite user-friendly)

If a track is Classical, Navidrome does the following:

• Adds all Composers, Conductors and Performers as additional song artists
• Uses Movement Number (movement/mvin)+ Movement Name (movementname/mvnm) tags instead of Track Title (title/tit2) tag
• Displays the Work Name (work/tit1) + Composers/Arrangers in the album tracklist (Navidrome Web UI only, not Subsonic API)
• Albums and tracks have a property classical=true/false that can be used in smart playlists

{
  "all": [
    {"is": {"classical": true}}
  ],
  "sort": "year",
  "order": "asc",
  "limit": 100
}

No changes for users without Classical music in their collection

[github-actions]

Download the artifacts for this pull request:

• binaries.zip
• js-bundle.zip

[Tolriq]

Please check the OpenSubsonic part about contributors and roles, if you support composers and all the relatives they can be exposed properly to OpenSubsonic clients that could make great use of the data. (Will require that you store the data accordingly in the DB even if not exposing it yet as OS data, properly preparing the data will help if you add future support)

[certuna]

OpenSubsonic support with roles/etc will likely have to wait until we do a full refactoring of the database.

I could do it in a hacky way and put multiple role/artist (or role/artistID)pairs in a single DB field (like id3 does it with TMCL/TIPL) and then pull them out and split for the API, but I don't really want to do that, not if a DB refactoring with proper m2m relations is around the corner.

Up to Deluan to say, I think.

[Tolriq]

I was mostly pointing that since the future is OpenSubsonic for clients to be able to consume the data, it's important that what you do now does not become a much more complicated breaking change later.
Anything not OpenSubsonic or Subsonic from API pov is limited to the Navidrome web interface and not usable from other clients.

[MRodneyMcKay]

Can we have an ETA on the DB refactoring, so this could get merged?