Build cache: task filters pollute cache keys for unaffected projects

Expected Behavior

Filters that don't affect a project's effective task list should not change its cache key.

Current Behavior

--include-task / --exclude-task are baked verbatim into the build base signature
shared across every project in the graph. Filters irrelevant to a project (e.g. a task that
doesn't exist for that project type) still change its cache key, causing unnecessary rebuilds
when building the same project via different entry points.

Root cause

BuildContext computes _buildSignatureBase from the raw includedTasks/excludedTasks
arrays and passes it unchanged to every ProjectBuildContext. But composeTaskList only
applies a filter when the task exists in the project's allTasks — so two builds with
different but equally-irrelevant filters produce identical effective task lists yet different
cache keys.

Steps to Reproduce the Issue

1. Build a root application with --include-task generateVersionInfo. Dependent libraries
   cache under a signature encoding includedTasks: ["generateVersionInfo"].
2. generateVersionInfo doesn't exist for library projects — no effect on their builds.
3. Build a library standalone (no flag). Signature now has includedTasks: [] → cache miss
   → full rebuild despite identical inputs and identical effective task list.

Fix direction

Move include/exclude contribution from getBaseSignature into the per-project signature
(getProjectSignature), keyed on the resolved output of composeTaskList rather than the
raw filter arrays.

Context

• UI5 Module Version (output of ui5 --version when using the CLI): 5.0.0-alpha.7

Start with BuildContext and ProjectBuildContext, following getBaseSignature, getProjectSignature, and composeTaskList. Verify how resolved task lists affect each project's cache signature, then test that irrelevant include or exclude filters produce the same key and avoid an unnecessary rebuild.