ci: scan each published package as its own FOSSA project

[hkad98]

Summary

Follow-up to #1596. Switches the FOSSA workflow from a single gooddata-python-sdk project (with all 8 packages' deps merged) to one FOSSA project per PyPI artifact: gooddata-sdk, gooddata-pandas, gooddata-dbt, gooddata-fdw, gooddata-flight-server, gooddata-flexconnect, gooddata-pipelines, gooddata-api-client.

This is the orthodox FOSSA model for a monorepo that publishes multiple artifacts:

• Each PyPI package gets its own license inventory, attribution report, and policy gate — aligned with what users actually pip install.
• The FOSSA branch axis is freed up for its intended purpose: tracking license drift across git branches (master, release/x.y) over time, rather than being repurposed as a component separator (the legacy fossa_gd_* pattern).
• New workspace packages onboard by adding one matrix row to the workflow + auto-creating the FOSSA project on first scan.

The legacy gooddata-python-sdk FOSSA project keeps its historical fossa_gd_* branch snapshots (e.g. the Oct 2023 fossa_gd_api_client scan); new dispatches no longer write to it. Local fossa analyze calls still target the legacy project via the committed .fossa.yml, intentionally — ad-hoc local runs cannot accidentally pollute the per-package projects.

Implementation

• workflow_dispatch trigger (unchanged).
• strategy.matrix over 8 packages, fail-fast: false so one package's policy failure does not mask the others.
• Each shard rewrites .fossa.yml with that package's project.id and paths.only, then runs fossa-action's analyze and test steps.
• Branch label defaults to github.ref_name (the dispatched git ref) with an optional manual override input.

Prerequisites for the first green dispatch

• The seven new FOSSA project ids (everything except gooddata-api-client, which exists already as a legacy artifact) must be auto-creatable on first scan, or pre-provisioned by a FOSSA admin if your org restricts project creation.
• Confirm with whoever owns the FOSSA contract that moving from 1 to 8 projects has no licensing/billing impact under the current plan.

Test plan

JIRA: TRIVIAL
risk: nonprod