Build cache: task filters pollute cache keys for unaffected projects

[matz3]

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