fix(project): Route Theme-Library Resources in BuildReader

[RandomByte]

Summary

Theme libraries have no namespace and serve their resources under a path owned by another project, for example themelib_sap_horizon serves /resources/sap/ui/core/themes/sap_horizon/library.css. BuildReader routed such a request by walking the path and matching the sap/ui/core namespace of the sap.ui.core library, which does not own the resource. The read returned null, so the reader fell back to requesting a reader for every project. That fallback (re)builds every non-fresh project, including libraries such as sap.m that have nothing to do with the theme.

Problem

BuildReader.byPath used a single best-guess reader from _getReaderForResource, then a single fallback to a reader for all projects. Namespace matching is path-based, so a theme resource served under another project's namespace segment resolves to the wrong project, reads null, and drops straight to the all-projects fallback. Requesting a reader for all projects is the expensive path: it (re)builds every stale project in the graph, so a single theme request could trigger unrelated builds.

Fix

Replace the single best-guess reader with an ordered list of candidate reader factories, evaluated lazily by byPath, returning the first resource found. A reader is requested from the build server only when the preceding candidates did not yield the resource, so the minimal set of projects is built.

The candidate order, most specific and cheapest first:

1. Cached readers of already-built projects. Free to query, and a hit identifies the owning project without building anything.
2. Namespace matches, most specific first.
3. Theme libraries, when the path has a themes/ segment. Theme libraries are tracked separately at construction time because they have no namespace to match on.
4. The application root project, for paths outside /resources/ and /test-resources/.
5. All projects. Last resort, reached only when no more specific strategy located the resource.

The base theme, owned by sap.ui.core itself, still resolves at the namespace step (2) and builds no theme library.

Naming

_getReaderForResource returned a single reader; the new method returns the ordered candidate list and is named _getReaderCandidates.

Testing

An integration-style harness records which projects a single byPath request would build, standing in for the build the BuildServer triggers for a non-fresh project. Three tests cover the routing:

• A colliding theme resource (themelib_sap_horizon under the sap.ui.core namespace) resolves from the theme library, and unrelated projects (sap.m, the application) are not built.
• A base-theme resource resolves from its owning library without building any theme library.
• A non-colliding theme resource routes to its theme library without falling back to all projects.

The two theme-library routing tests were added first and failed against the previous fallback-to-all behavior. The base-theme test passed before the fix and still passes.