Avoid PHP 8.5 deprecation notice when loading the tracker

[sgiehl]

Problem

PHP 8.5 deprecated the predefined locally scoped $http_response_header variable, and reports it at compile time. The stream transport's pre-8.5 fallback read therefore made merely loading MatomoTracker.php emit a deprecation — even on 8.5, where the branch that actually runs is http_get_last_response_headers():

$ php -r "include 'vendor/matomo/matomo-php-tracker/MatomoTracker.php';"
Deprecated: The predefined locally scoped $http_response_header variable is deprecated,
call http_get_last_response_headers() instead in .../MatomoTracker.php on line 2419

Because it fires on include rather than on use, it can neither be suppressed with @ nor avoided by the function_exists('http_get_last_response_headers') guard. Tools that turn diagnostics into exceptions abort while autoloading the class — the reporter hit this with Psalm 6.16.1, which crashes evaluating class_exists('\MatomoTracker') in PiwikTracker.php:17 — and applications that log deprecations get one entry per include.

Reported by @Baffos in #155.

Fix

Assign the variable before the fallback reads it. That silences the compile-time diagnostic while keeping the pre-8.5 fallback working, and is the shape 3.4.0 used. Header handling is otherwise unchanged: http_get_last_response_headers() is still preferred whenever it exists.

Alternatives were checked and rejected:

• A dedicated helper method cannot work — the engine populates the variable in the frame that called file_get_contents(), so a helper reading it sees nothing.
• get_defined_vars()['http_response_header'] ?? [] is a trap — it silences the 8.5 diagnostic but returns nothing on 8.1–8.5 alike (no CV exists), silently breaking incoming Set-Cookie parsing on PHP < 8.5.
• Dropping the fallback isn't possible while 8.1–8.4 are supported, since the stream transport is the no-cURL path.

Note the fix is order-sensitive: moving the assignment below the read reintroduces the notice (verified — an assignment the compiler has not yet seen does not help). That's what the new test guards.

Notes

• Verified in php:8.5-cli: the deprecation is emitted on master and gone with this change. Also verified the pre-assignment does not mask real headers — with a sentinel value, PHP replaces it with the real response headers (incl. Set-Cookie) on both 8.1 and 8.5, and end-to-end incoming-cookie parsing over the stream transport still works on both.
• Added testLoadingTheTrackerEmitsNoDeprecationNotice, which loads the tracker in a clean subprocess and asserts it emits nothing. Confirmed it fails on 8.5 without the fix and passes with it; CI already covers 8.5. It runs with -n so an unrelated php.ini extension line in a contributor's environment can't turn into a false failure (confirmed both ways).
• phpunit (156 tests), phpstan (level max) and phpcs are clean; the suite passes on 8.1, 8.3 and 8.5.
• Possible follow-up, deliberately left out of this PR: phpunit.xml.dist has no failOn* flags, and --fail-on-deprecation alone would have caught this bug class in-process (verified: it exits 1 on master under 8.5). Adding failOnDeprecation/failOnWarning/failOnNotice passes cleanly with this fix, but it changes strictness for the whole suite, so it seemed like your call rather than a drive-by.