This is necessary because `zend_get_attribute_object()` will use the persistent
string with the parameter name as the index for a newly created non-persistent
HashTable, which is not legal.
As parameter names are expected to be short-ish, reasonably common terms and
need to sit around in memory anyways, we might as well make them an interned
string, circumstepping the issue without needing to duplicate the parameter
name into a non-persistent string.
0242577b33 partly fixed the detection of external constant lists referenced on Predefined Constants pages, but changing the file search regex is needed too in order to fully fix the underlying issue in case of cURL constants.
Some constants are extracted from Predefined Constants pages (e.g. https://github.com/php/doc-en/pull/3413), which should alsobe checked when verifying the manual.
Basically all constants are now declared via stubs. The rest of the constants are either deprecated (`SID` or `MHASH_*`) or out of interest (`__COMPILER_HALT_OFFSET__` and `PHP_CLI_PROCESS_TITLE`).
- Declared compatibility expectations of stub files are now enforced by a ZEND_STATIC_ASSERT call at the top of arginfo files
- Property registration for PHP 7 is fixed: function zend_declare_property_ex() is used again instead of zend_declare_typed_property(). This has been a regression since I added support for exposing doc comments.
- As a defensive measure, deep cloning is performed before newer features (type declarations, attributes etc.) are discarded before generating legacy arginfo files. Until now, some of the objects were forgotten to be taken care of. These omissions may have resulted in some weird bugs in theory (but probably they didn't have much impact in practice).
- PHP version related conditions inside *non-legacy arginfo files* used to possibly check for the 70000 version iD until now if compatibility with PHP 7.0 was declared in a stub. This was not 100% correct, since non-legacy arginfo files are only for PHP 8.0+. Now, I made sure that at least PHP version ID 80000 is used in the preprocessor conditions. The solution was a bit tricky though...
In the same time, let's not verify implementation aliases since they may now legitimately differ from their aliased function/method counterparts (think about the ext/dom refactoring where e.g. many return type declarations have changed). Additionally, unnecessary `@no-verify` tags are cleaned up.
Now that we have class aliases (DOMNode -> DOM\Node), it has become important to add them to the class map so that it will be possible to generate class synopses for them.
Additionally, let's make sure that we don't try to process the stub files in the
manual target directory. This comes with a slight performance benefit.
