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.

Examinez les exemples de dépendances et les références à main/php_config.h, main/streams, ext/standard, ext/hash, TSRM, Zend et zend_system_id, puis lisez les discussions liées des pull requests. L’issue n’a pas de cible d’implémentation définie ; sa résolution nécessiterait de convenir d’une approche concernant le sens des dépendances entre modules et leurs conséquences pour le système de build.