Ensure that the tests find the built python module vs an install

[kdt3rd]

This may have a slightly messy un-intended consequence of "snap-shotting" pythonpath when configured in a large python env, but eases testing confusion on systems where pythonpath is not yet set, but an (older) copy of OpenImageIO is installed.

This fixes the python tests on my home machine.

Checklist:

• [x] I have read the contribution guidelines.
• [ ] I have updated the documentation, if applicable.
• [x] I have ensured that the change is tested somewhere in the testsuite (adding new test cases if necessary).
• [ ] If I added or modified a C++ API call, I have also amended the corresponding Python bindings (and if altering ImageBufAlgo functions, also exposed the new functionality as oiiotool options).
• [x] My code follows the prevailing code style of this project. If I haven't already run clang-format before submitting, I definitely will look at the CI test that runs clang-format and fix anything that it highlights as being nonconforming.

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: kdt3rd / name: Kimball Thurston (1340c90bab7d737e2942e94284de4138c6f18bf6, 04848f029cb95e5623f6a5699cd9f4b96bde2d5a, 4e08f52c14b3173e372bf3a3aba46655e9026488)

[kdt3rd]

With the latest commit, I can cleanly run the test target from the build folder (assuming I have previously downloaded the test images) without running an install, which eases the development workflow. I do not have a windows machine to test with, but windows (and ninja multiconfig) have multiple configs, so to avoid potential slicing, put the python modules in the appropriate config path - and copied the init.py in there such that it might work to load the dlls under windows (untested). Given that the CI runs the tests using the installed dist tree, I have disabled overriding the env variables in this scenario