[php-src] Issue #21970: Feature Request: Introduce `undefined` sentinel type for explicit "missing" state

Issue: https://github.com/php/php-src/issues/21970
Author: ryhor-vasilkou

### Description

Disclaimer: "the power is in details" - save 1 second every 5 seconds and you save 1 year every 5 years.

PHP currently relies on null to represent the absence of a value.

While we have the isset() language construct, it does not cover all architectural scenarios, forcing developers to write redundant checks and manual logic to handle default parameters.
 
I propose introducing an undefined type/keyword to solve the "proxying" problem and distinguish between "no data" and "null data"


**Problem 1: Broken Default Parameter Logic in Wrappers**

Currently, it is impossible to programmatically pass a "missing" state to a function to trigger its default value mechanism.

```php
function my_custom_func($value = 123)
{
    var_dump($value);
}

my_custom_func(); // "123", correct
my_custom_func(null); // null, correct
//
my_custom_func($i_dont_know_what_is_inside_my_variable); // null (only NULL, making it impossible to distinguish between a missing value and a legitimate null. This forces developers to use clunky workarounds, such as passing arrays just to check for emptiness)
```

This issue is frequent when writing libraries.

If a function (made by developer1) is wrapped by another function (made by developer2), the developer2 must manually sync default values between them.

If the internal library updates its default value, the wrapper breaks too.

Using ($var ?? undefined) would solve this.


**Problem 2: Array Mapping and No-op states**

There is no clean way to return a "do nothing / skip assignment" state in callbacks.

```php
function my_custom_array_map_handler($v)
{
    my_custom_action();

    return null; // ==> $arr[0] = NULL
    return $v; // ==> $arr[0] = (untouched)
    //
    // return undefined; // > possible 2nd use-case, avoid assign operation internally
    // (no return at all); // > possible 3rd use-case, function may return `undefined` instead of `null` and can be checked using `is_undefined` to ensure there's no return value
}

$arr = [1,2,3];

$arr = array_map('my_custom_array_map_handler', $arr); // map behavior
array_map('my_custom_array_map_handler', $arr); // tap behavior, internally assign operation
```


**Problem 3: Data Integrity in API/DTO layers**

When handling Form Data, we need to distinguish between:
An empty input (user wants to clear the value) or a missing input (field was not sent, do not touch the database).

(Its like common mistake using checkbox on any website - its TRUE or FALSE, but... Actually, it can be "NON-TRUE" or "NON-FALSE" in complex filtering logic, but its not about PHP, guess web-standarts issue)

New type `undefined` provides a clean context: "this data has been already processed by validation/filter layer, and I know it should not be touched".

Loose Equality: To prevent the "JavaScript-style" complexity, it is proposed to make `null === undefined` always returns `true`.

This maintains backward compatibility for existing null-checks.

Also implement `internal` check: A specific is_undefined() function or internal check would be used only when the distinction is strictly necessary.

Behavior: Passing undefined to a function argument triggers the default value defined in the signature.

This feature would eliminate massive amounts of if-else boilerplate and func_num_args() calls that currently make type-hinted signatures dangerous rather than helpful.