VorbisComments: Parse TRACKNUMBER with respect to implicit_conversion

[Methapon2001]

Summary

Fixes #540.
This PR make VorbisComments parse TRACKNUMBER with respect to ParseOption::implicit_conversions

Note

Let me know if there is something more that should be done.

I'm not sure if I need to update the Accessor for VorbisComments. The goal is to ensure that track and track_total can still be called and return u32 values, even when the format is <current>/<total>.

	fn track(&self) -> Option<u32> {
		if let Some(item) = self
			.get("TRACKNUMBER")
			.map_or_else(|| self.get("TRACKNUM"), Some)
		{
			return item.split('/').next().and_then(|v| v.parse::<u32>().ok());
		}

		None
	}

What do you think?

[Serial-ATA]

Thanks!

The goal is to ensure that track and track_total can still be called and return u32 values, even when the format is <current>/<total>.

Hm, I'm not sure how I feel about Accessor methods handling multiple data formats like that. Generally, I prefer modifying the data at parse time, and having Accessor assume that's the case. That's what implicit_conversions warns about in the docs: https://docs.rs/lofty/latest/lofty/config/struct.ParseOptions.html#method.implicit_conversions

[Methapon2001]

Thanks!

The goal is to ensure that track and track_total can still be called and return u32 values, even when the format is <current>/<total>.

Hm, I'm not sure how I feel about Accessor methods handling multiple data formats like that. Generally, I prefer modifying the data at parse time, and having Accessor assume that's the case. That's what implicit_conversions warns about in the docs: https://docs.rs/lofty/latest/lofty/config/struct.ParseOptions.html#method.implicit_conversions

All right, then the current behaviors should be as expected. I also added 2 test cases.

[Serial-ATA]

I went ahead and removed the test files, for a simple case like this it's best to just create the tag in the test