add config-secrets option to allow-list secrets in workflows

[tdeo]

Fixes #609

I did use claude-code to open this because I'm not familiar at all with go. I tried to review the changes as best I could but apologize in advance if this is not good enough.

Summary

• Adds a new config-secrets configuration option in actionlint.yaml, parallel to the existing config-variables option
• When set to an array of secret names, actionlint reports any secrets.XXXX access where XXXX is not in the list (case-insensitive)
• Default value null disables the check; an empty array disallows all secrets
• Updates docs/config.md with documentation and usage example

Test plan

• New project-level integration test in testdata/projects/config_secrets/
• New unit tests in TestExprSemanticsCheckOK for secret, known secret, and secret name is case insensitive
• New unit tests in TestExprSemanticsCheckError for no secret is allowed and unknown secret
• All existing tests pass (go test ./...)
• staticcheck ./... passes cleanly

[rhysd]

Since this change seems to be generated by Claude, let me ask a question. Did you review the generated code, confirmed the test results, and validated the behavior with actual config files?

[rhysd]

I don't think this fast path is necessary because the below error message is comprehensive enough.

[tdeo]

Do you think we should also remove the same fast path from checkConfigVariables just above?

[tdeo]

@rhysd do you have any opinion whether I should handle checkConfigVariables at the same time?

[tdeo]

Since this change seems to be generated by Claude, let me ask a question. Did you review the generated code, confirmed the test results, and validated the behavior with actual config files?

Hello, that's a very good, while I didn't know anything about go and not much about this project's internal, what I did review myself was:

• that the generated files under testdata/ made sense, that they were implemented in a very similar way to what exists for config variables and that the output is the behavior I would expect for a project with that workflow and configuration
• that the implementation of checkConfigSecrets seemed to be coherent with what existed for checkConfigVariables
• that the test suite still worked locally (claude was able to run it by itself)
• I did see that the signature change to NewExprSemanticsChecker may not be what we want long term and possibly it would be better for it to receive a config object instead of individual values but I didn't think such a change was appropriate in this PR and I had no idea how to start

Overall, I did think opening a PR was a good way to get the conversation started about #609