Add separate ID3v1 support

[26fe]

Summary

Add dedicated APIs for reading, writing, and removing trailing ID3v1 tags without changing the existing ID3v2 API behavior.

Motivation

An MP3 file can contain both ID3v2 metadata at the beginning and an ID3v1 tag at the end. Applications that update only ID3v2 may leave stale ID3v1 metadata in the same file.

Depending on which tag format a player reads, users may then see different titles, artists, albums, years, track numbers, comments, or genres.

These APIs allow applications to explicitly:

• Keep compatible ID3v1 fields synchronized after writing ID3v2.
• Remove ID3v1 when the application intends to maintain only ID3v2.

For example, an application can update ID3v2 and then write the corresponding ID3v1 fields:

NodeID3.update(tags, filepath)

NodeID3.writeId3v1({
  title: tags.title,
  artist: tags.artist,
  album: tags.album,
  year: tags.year,
  trackNumber: 3,
  genreId: 17
}, filepath)

Alternatively, an application that uses only ID3v2 can remove stale ID3v1 metadata:

NodeID3.update(tags, filepath)
NodeID3.removeId3v1(filepath)

The operations are deliberately separate. This preserves backward compatibility and lets each application decide whether ID3v1 should be synchronized, preserved, or removed.

Changes

Add readId3v1(), writeId3v1(), and removeId3v1().
Support Buffer and filepath inputs.
Support synchronous, callback, and Promise APIs.
Add comprehensive ID3v1 tests.

Validation

npm test: 85 passing
npm run eslint: passing