Add SimpleCacheV3Test for PSR-16 v3 strict type hints (#121)

[GautamMKGarg]

Closes #121 (with the help of AI agents)

PSR-16 v3 (psr/simple-cache ^3.0) introduced strict PHP type hints:

• string $key
• iterable $keys
• null|int|\DateInterval $ttl

This caused the existing SimpleCacheTest data providers to throw \TypeError
before implementation code ever ran, making many tests effectively broken for
v3 consumers.

What this PR does

1. Adds SimpleCacheV3Test — a new subclass of SimpleCacheTest that:

   • Filters invalidKeys() and invalidArrayKeys() to only string invalid
     keys (non-string types are rejected by PHP before reaching the library)
   • Filters invalidTtl() to values that don't coerce to valid int/null in
     PHP weak mode
   • Introduces assertCacheExceptionOrTypeError() helper that accepts both
     \TypeError (PHP-level rejection) and InvalidArgumentException
     (library-level validation) as valid failures
   • Adds testBasicUsageWithLongKey64() — tests the PSR-16 mandated
     minimum key length of 64 characters

2. Updates composer.json — adds psr/simple-cache: ^1.0 || ^2.0 || ^3.0
   to require-dev so the test suite can be developed against any version

3. Updates README.md — documents SimpleCacheV3Test usage

Backward compatibility

SimpleCacheTest is completely untouched. Existing v1/v2 consumers continue
using it without any changes. V3 consumers switch to SimpleCacheV3Test.

Tested against

• Verified with gautammkgarg/psr-for-wordpress
  (Packagist) —
  a real PSR-16 v3 WordPress bridge implementation (transients + object cache
  adapters, 466 tests, 2251 assertions, all passing)

[stof]

I think we should have a single test class, to make it easier for projects supporting multiple versions of psr/cache in parallel.
If some data providers need to provide different values depending on the psr/cache version, you could use InstalledVersions from the composer-runtime-api for that. However, I'm not even sure this should be the case. You could have psr/cache 2+ installed while not having native types on parameters in the implementation (which is the way to support version 1 and 2 at the same time). Testing inputs that violate the contract should probably be moved to separate data providers used by tests using assertCacheExceptionOrTypeError