Add proper support for SDL2's new versioning scheme

[a-hurst]

PR Description

Closes #228.

This PR fixes the unit tests that expect the SDL2 minor version to always be 0, and also updates the internal version string-to-int and int-to-string functions to correctly parse the new versions. Note that the updated code assumes that the patch level for future SDL2 releases will always be a single digit, which I think seems safe.

Merge Checklist

• [x] the PR has been reviewed and all comments are resolved
• [x] all CI checks pass
• [x] (if applicable): the PR description includes the phrase closes #<issue-number> to automatically close an issue
• [x] (if applicable): bug fixes, new features, or API changes are documented in news.rst

[smcv]

Note that the updated code assumes that the patch level for future SDL2 releases will always be a single digit, which I think seems safe.

I'd really prefer not to have more artificial constraints like this: we only narrowly managed to get away from the version number being limited to 2.9.99, by making SDL_VERSIONNUM let the minor version overflow into the thousands digit, which is safe because the major version of SDL 2 is always going to be 2 (SDL 3 will be incompatible anyway, and will remove SDL_VERSIONNUM).

I started on a branch that adds sdl2.dll.DLL.version_tuple, in the style of sys.version_info, which I think is a more future-proof approach to this. I'll try to finish that soon and propose a PR.

[smcv]

This actually doesn't close #228, either: it would fail tests against SDL git master, because 2.23.0 does not have patchlevel >= 5 (and so on for the other libraries).