Python 3 compatibility

[MrDOS]

This PR updates the library for compatibility with Python 3.

• Unlike Add python3.x support #17 (which I referenced – thanks, @talolard), it drops Python 2 compatibility. (I think at this point it's probably safe to discourage people still running Python 2 from connecting those machines to the Internet!)
• It replaces the setup.py library definition with a pyproject.toml file. This does change the development workflow a bit (requires an editable installation into a venv), but shouldn't have any ramifications for downstream consumers of the library.
• Nose has been totally discontinued, and doesn't even import in Python 3.12+ due to a dependency on imp, so unit tests have been rewritten to use pytest. I've also added a GitHub Actions workflow to run them automatically.

If merged, this would supersede #17 and #30.

Please note also the message of the first commit in the series:

I've specified the “GPL-3.0-or-later” license on the basis that, at the
time it was committed, the license URL in setup.py linked to the text
of GPL 3.0, and in my experience, “or later” is the typical expectation
of forward GPL version compatibility when left unspecified.

If you can provide confirmation or clarification of your intent, @ocelma, I'll happily reword the message to be less speculative.

[MrDOS]

I'm certainly not trying to scrub attribution out of the source file; it just seems like Python libraries these days tend to convey this information solely via pyproject.toml, rather than these dunder attributes. If you'd prefer to keep them, I can look at using dynamic fields in pyproject.toml so that they only need to be specified in one place.

[MrDOS]

I wasn't sure what to put here: 0.2 (from __init__.py), 1.0 (from setup.py/PyPI), or 1.0.0 (i.e., take the opportunity to switch to a SemVer/Pride Versioning-style triple-barrel version number). In the end, I decided it was probably best to keep editorial changes out of this PR as much as possible, and so I kept 1.0.

[MrDOS]

Thank you for merging so quickly! This library has been very useful to me for eight or nine years now as part of my music library management (I use it for automated retrieval of high-resolution album art), and I hope Apple don't turn the lights off on the API any time soon.