feat(ci): ship reusable GitHub Action for fbuild install + cache setup (external consumers)

[zackees]

Goal

Make fbuild drop-in usable in consumer CI pipelines with a single step:

```yaml

• uses: FastLED/fbuild/.github/actions/setup@v1
  with:
  cache-key-extra: ${{ hashFiles('platformio.ini') }}
• run: fbuild build examples/Blink -e esp32dev
  ```

Today, consumers must read docs/CI_CACHING.md and hand-wire `actions/cache@v4` + install + env vars. That's error-prone (especially the exclude-daemon-dir pitfall).

What the action does

• Install fbuild from PyPI at the requested version (default: latest)
• Set `FBUILD_CACHE_DIR` to a stable CI-predictable path (so no $HOME dependence)
• Wire `actions/cache@v4` to save/restore that dir across runs using the cache-key strategy documented in `CI_CACHING.md`
• Exclude `~/.fbuild/*/daemon/` automatically (the gotcha)
• Output: `cache-hit` (bool) so consumers can assert warm-builds in a smoke step

Scope

• Composite action at `.github/actions/setup/action.yml`
• README in the action dir with usage + inputs reference
• Update `docs/CI_CACHING.md` TL;DR to recommend the action (keep the raw-YAML snippet for consumers who don't want the action dependency)

Out of scope

• A JavaScript action (composite is sufficient, no build-tooling overhead)
• Windows-specific quirks beyond what `actions/cache@v4` already handles
• Matrix sharding with persistent volumes (one-shot runners only)

Follow-up

• After this action lands, switch FastLED repo workflows to use it. That's a separate PR in the FastLED repo.

Acceptance

• Action exists at `.github/actions/setup/action.yml`
• Action tested in at least one fbuild internal workflow (self-test against the repo's own build matrix)
• Consumer-facing README in `.github/actions/setup/README.md`
• `docs/CI_CACHING.md` references the action as the preferred path
• FastLED CI switched over in a companion PR in that repo