This provides an `angular:signal_graph` in-page tool which exposes the signal graph from the component rendered for a particular DOM element. It leverages the algorithm defined for Angular DevTools, which essentially means it takes the effects registered on the components injector and walks transitive dependencies to find all signals referenced by the component in an effect or the template.

This will centrally manage all the AI tools supported by Angular out of the box.

This registers AI runtime debugging tools during platform creation and unregisters them when the platform is destroyed. This roughly matches existing usage of global utils with respect to timing. It is limited to dev mode only because these tools are exclusively for debugging Angular's internals and not something production users would leverage.

This walks all transitive descendant directives via the `LView` structure of the given input. This is a generic utility, but useful for finding all components in a tree to look for their associated `Injector` objects.

One known limitation is that this does not cover child components of i18n messages as that was more complicated than I wanted to get into right now.

This creates a new `angular:di-graph` in-page tool which returns the entire dependency injection graph for the application.

We use the following rough algorithm for discovering all element injectors:
1. Find all root `LView` objects by querying for `[ng-version]`.
2. Walk all the transitive `LView` descendants of the roots.
3. Filter these `LView` objects to just directives.
4. Find the injector for a given directive and walk up its ancestors to find all element injectors.

Discovering environment injectors works mostly the same way, just following the environment injector graph instead.

This approach has a few known limitations which are out of scope for the moment:
1. Any given component typically has both an element injector *and* an environment injector. The relationship of "component -> environment injector" is not expressed in the result as of now, meaning the AI doesn't really have any insight into _which_ environment injector is being used for a particular component, though the injector will be one of the returned values.
2. The implementation does not support MFE use cases of multiple applications on the page at the same time.
3. The performance is not ideal, as we walk `LView` descendants twice and walk up the injector tree for every directive, repeatedly covering the same scope (ideally we'd just walk up every *leaf* directive, which would cover the same result for less effort). However for a debug tool, this is likely fine for now and we can optimize later if/when it becomes necessary.

I did consider reusing more of the existing implementation in `global_utils` which exists to support Angular DevTools (we are already using some of it), however the existing support in `@angular/core` is actually fairly limited, returning very primitive data structures and relying on Angular DevTools to do the heavier lifting of collapsing the code into a usable graph representation. There's a potential path in the future to converge these implementations and potentially have `global_utils` use some of this code instead, but I will leave that for a future cleanup effort.