feat(build): add CLI options for custom engine artifact sources

[sbs44]

Summary

Add CLI options to download engine artifacts from custom GitHub repositories and workflow runs, enabling testing of custom engine builds before they are officially released.

New options (hidden by default, shown with --verbose)

• --github-artifacts-repo=<owner/repo> - Use a custom GitHub repository for engine artifacts
• --github-artifacts-runid=<run-id> - Download from a specific GitHub Actions workflow run
• --github-artifacts-engine-version=<hash> - Specify the engine version in the workflow artifacts
• --github-artifacts-auth-token=<token> - GitHub authentication token (also reads GITHUB_TOKEN env)

Use cases

• Testing engine builds from forks before merging upstream
• Using custom engine builds for development/debugging
• Downloading artifacts from specific workflow runs

Example

# Test Pi5 engine from a fork's workflow run
export GITHUB_TOKEN=$(gh auth token)
flutterpi_tool build --release --arch=arm64 --cpu=pi5 \
  --github-artifacts-repo=myuser/flutter-ci \
  --github-artifacts-runid=12345678

Test plan

• Tested downloading artifacts from workflow run
• Verified GITHUB_TOKEN authentication works
• Built and deployed app with custom engine artifacts

[ardera]

this does the job, but it's a bit hacky

command parsing should be done inside the command, with the argParser. Two reasons:

1. All the tests are done by calling FlutterpiCommandRunner with fake objects in the context. Since the logic here is outside of commands and the command runner, this is hard to test as it is right now.
2. Harder to get the parsing wrong. (For example, your parser doesn't handle a user passing -- to terminate options, or a user passing --my-option-with-following-value --github-workflow-artifacts... (not that the latter would ever happen))

Maybe it's better to just add settable fields to the FlutterpiCache:
specifiedRepo, specifiedWorkflowRunId, specifiedAuthToken

And if e.g. workflow run id is set, source from workflow instead of releases.

That's a bit similar to how it's done for the device discovery.

IMO it's fine to leave away the auth token cmdline arg and just allow setting it via GH_TOKEN env var, if that makes implementation easier. And no need to differentiate here whether it's workflow / releases cache, GH_TOKEN is potentially useful for both.