Minor changes to support pytest

[ankith26]

A pleasant surprise: pytest seems to support unittest based tests out of box!

We've had occasional problems due to our custom test runner, and it seems like in the long term it's worth migrating to a tried and tested tool that handles stuff for us. The good part is that (after this PR) pytest test -k "not interactive" will be an alternate way of running tests that behaves like python -m test when running from the project directory, and the old machinery will still be default, and continue to work.

This PR is is needed because:

1. pytest does not understand our custom tags system. But pytest allows enabling/skipping tests based on patterns in the name. So interactive tests need to be explicitly marked as so in the name
2. pytest seems to run everything that begins with test_, so things that are not actually tests need a name changing
3. There was one package import that works better as a relative import

Future work

1. Make python3 -m pygame.tests/python3 -m test internally invoke pytest, maybe initially this should be controlled by an opt-in flag, but eventually it could be default
2. write any new tests in pytest
3. (optional) can incrementally port existing tests to pytest

[MyreMylar]

LGTM 👍 Simple changes.

I use pytest where I can on every python project that isn't pygame so this should be helpful.

[Starbuck5]

Why do we want to support pytest? I know it's related to the unit test runner not reporting helpful results when something segfaults, but what exactly does pytest do for us in that vein?

[ankith26]

pytest would not give that unhelpful error, and instead it should straight up give up at the segfault and report it exactly

[zoldalma999]

LGTM!

I don't see why we wouldn't support pytest as long as the old way works as well