gh-133982: Use implementation-specific open in test_fileio OtherFileTests

[cmaloney]

The tests around unicode filenames use both FileIO directly and open so kept using open for them / validates that unicode filenames passed through open() match behavior of FileIO called directly with an encoded name.

For the append tests it looks like FileIO directly is closer to what was intended, there is test_io that has append tests around self.open directly, this is test_fileio so intent I think was to test FileIO directly.

• Issue: Use implemenation-specific I/O open / constructors in tests #133982

[efimov-mikhail]

Is it worth backporting on 3.13? cc @Yhg1s

P.S. Congratulations with becoming Core Dev, @ZeroIntensity !!!

[ZeroIntensity]

We've been backporting these to 3.13 as far as I can tell.

[cmaloney]

Not sure policy: Is a test-only change which enables more testing of _pyio, a _io implementation CPython doesn't use directly at the moment.

The work I'm doing on top of these patches is adding another _io.Buffered* implementation which is runtime switchable, starting in a copy/paste of _io, new import that swaps implementation to ease side by side performance testing/integrating while having a working/building/running CPython. Hoping to land the feature in the 3.15 feature window, but lots of steps to get there (implementation, creating I/O benchmarks in pyperformance, testing compatibility, validating performance on range of systems, PEP, ...)