Avoid circular module dependencies

Description

This issue has been triggered by https://github.com/php/php-src/pull/15548#discussion_r1728965655 and https://github.com/php/php-src/pull/15522#issuecomment-2305279764.

To clarify the terminology: "modules" are not referring to compilation units (with their headers), but rather the bigger picture (e.g, Zend, TSRM etc.); and "dependencies" refer to compile time (not runtime) dependencies.

While obviously not required (C and our build system is fine with circular module dependencies), it might make sense to restrict module dependencies so they can represented as directed acyclic graph; that may at least help conceptually. Supposedly, a simple (sorry, I'm pretty unexperienced with Memaid syntax) dependency graph could like like the following ("PHP" means rest of php-src):

flowchart TD
  Zend --> TSRM
  streams --> TSRM
  streams --> Zend
  PHP -->TSRM
  PHP --> Zend
  PHP --> streams

However, TSRM already depends on main/php_config.h (which is not that bad since it is only a configuration header), but already Zend (the Zend Engine, to be precise) depends on quite some stuff in main/, and due to zend_system_id even on ext/standard and ext/hash. And main/streams/ depends on even more ext/standard headers.

Now the question is, are we fine with the current state (i.e. to have circular dependencies for the sake of simplicity, and not having to change anything), or do we want to "improve" this? If we're strict about avoiding circular dependencies, we could (at least in theory) even build the modules as shared libraries.

Esamina gli esempi di dipendenze e i riferimenti a main/php_config.h, main/streams, ext/standard, ext/hash, TSRM, Zend e zend_system_id, quindi leggi le discussioni collegate delle pull request. L’issue non ha un obiettivo di implementazione definito; per considerarla completata sarebbe necessario concordare un approccio alla direzione delle dipendenze tra i moduli e alle relative conseguenze sul sistema di build.