Issue #3628742: Fix set and deleted Session cookie in the same response when an invalid session ID is sent

Since strict mode was enabled for PHP sessions (#2631220), PHP replaces an unknown session ID sent by the client with a new one and immediately queues a Set-Cookie header for it.

When the request stores nothing in the session, SessionManager::save() treats the session as obsolete and calls SessionManager::destroy(), which sends a deletion cookie but leaves the header queued by PHP in place. The response then contains two Set-Cookie headers for the same cookie: one with a freshly generated (and never stored) session ID, followed by one with the value "deleted". This goes against RFC 6265 section 4.1.1 and exposes an unused session ID.

Symfony's AbstractSessionHandler::destroy() avoids this by removing the queued header via SessionUtils::popSessionCookie(), but Drupal's SessionHandler::destroy() overrides that method.

SessionManager::destroy() now removes any queued Set-Cookie header for the session cookie before sending the deletion cookie, keeping all other cookies intact. A functional test asserts that an invalid session cookie on a request with an empty session results in a single deletion header.

Closes #3628742