feat: Support for additional metadata and multi-value metadata (genre, composer)

[chme]

This PR are is a poc / rfc.
Its purpose is to revive the discussion about supporting more than one genre/compose for a song #886 and hopefully come to a solution.

It follows what @whatdoineed2do outlined as third option in #886 (comment):

• add supplementary meta table that can have linkage back to files entry
  this is the one I explored most and is still troubling to resolve. If we keep the main files table as it stands, where each cols like genre continue to hold only one item element and any additional elements can be held in the meta table that could be name-value pairs

As described in the comment a new table is introduced files_metadata that links to the files table and contains key / value pairs. A file can have multiple entries for a key.

When scanning a file with ffmpeg the files_metadata table is populated. Genre and composer tags are split by separators (currently hard-coded, should be configurable) and multiple rows are inserted for the file in files_metadata.
files_metadata entries are not updated, if a file changed, all rows for this file_id are deleted and new ones are inserted.
The scan logic for the files table is unchanged.

To fetch via the files_metadata table, new query_types are added for genre / composer browse queries.
The existing queries and usages to fetch from the DB are unchanged.

The JSON API was updated to show how the queries can be used (note, that this currently breaks the web UI).
How the JSON API should be changed in the end, needs further thought (e. g. if it is OK to have breaking changes or not).

In my opinion, this solution has several advantages:

• Support multi-value tags like genre and composer is now possible.
• The new files_metadata table allows to easily expose additional metadata fields without impacting existing queries. In this PR for example, I added several MusicBrainz IDs (the web UI could e. g. make use of them to fetch additional data from external service).
• Currently lyrics are stored in the files table, which increases the result set size for files queries by a lot (assuming a user that has a lot of files with lyrics tags). Lyrics are only relevant when looking at a single file/song, e. g. in the now playing page or in the file/song details dialog. But most or all of the time a list of songs is fetched, they are not relevant. This might also apply for other tags, and could improve the query execution times for large libraries.
• It can be implemented without breaking the existing APIs.

There are of course some limitations or difficulties with this approach:

• Support for files_metadata in smart playlist queries will be difficult and most probably - if possible at all - not performant.
• Genre / composer duplicated in files and files_metadata. But I would argue here that this is OK. In the files table is the raw value from the scan, while in files_metadata are the parsed/processed values. And also not normalizing a DB to improve performance is in my opinion also OK.

@ejurgensen, it would be great if you could take a look and say whether this approach is OK and worth fleshing out and looking into in detail.