Investigate updating fork access

[sk593]

Forks and Dependabot needs access to AWS keys to run tests on opened PRs. Access should be added or we should remove setting secrets if it's not needed

Test runs from forks will fail with the following error:
Error: Credentials could not be loaded, please check your action inputs: Could not load credentials from any providers as a result of using this packageaws-actions/configure-aws-credentials@v4. See this PR run for details: https://github.com/radius-project/bicep-types-aws/actions/runs/11147276332/job/30981202815?pr=62

We might not need this package to configure credentials since we're pulling from CloudControl specs to generate AWS types. We should look into whether credentials are needed. If they aren't needed, we should remove this step. If they are needed, we should investigate how to give forks the correct access to run tests on PRs.

AB#13379

[sk593]

For Dependabot triggered PRs, we can add credentials to Dependabot to get the workflow passing. This will need to be done by a maintainer.

For other forks, there are some suggestions on how to go about this. This will need further investigation as want to make sure we're not giving write access to forks. See here for details: aws-actions/configure-aws-credentials#188

Options for other forks:

• pull_request_target:
  This has been suggested in a few of the issues on the configure-aws-credentials repo as a workaround to the above issue. pull_request_target gives write permissions to the target repository so this cannot be used on it's own. We'd need additional protections to ensure that unwanted changes aren't tested. See here for more information on how to use pull_request_target securely: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/

• workflow_run:
  This is similar to how we run cloud tests in the Radius repo. We have someone with access to the repo trigger the functional test runs by approving the PR. See here for more details: https://github.com/radius-project/radius/blob/719cb51a0cb09c1d55f37e3030769031cf48bffc/.github/workflows/functional-test-cloud.yaml#L41C1-L42C44 and https://github.com/radius-project/radius/blob/main/.github/workflows/functional-tests-approval.yaml

workflow_run would be ideal so we don't add additional security vulnerabilities and there's already a precedent for that approach in the Radius repo

[sk593]

Addressed via: #85