Add a flag to allow us to override the aws credentials profile that the credentials are saved under.

[tunderwood]

Description

Currently we allow the AWS profile name the credentials will be saved under via the configuration file (either per profile or via inheritance) or via a environment variable. This PR adds a feature flag that will allow users to specify --aws-cred-profile <profile name>. This flag would take precedence and override both the environment variable if set and the profile from the configuration file. This allows tooling to standardize profile names even if a user has a profile specified that they prefer for use outside of that tooling.

Related Issue

#499

Motivation and Context

The cred_profile setting can currently be set via the config file or the GIMME_AWS_CREDS_CRED_PROFILE environment variable, but there is no CLI flag to override it per-invocation. This is inconsistent with other settings like output_format, which supports all three layers: config file, environment variable (GIMME_AWS_CREDS_OUTPUT_FORMAT), and CLI flag (--output-format).
A CLI flag is useful when switching credential profile strategies on the fly — for example, writing to a specific named profile for a one-off script or CI job without modifying the config file or polluting the shell environment.

How Has This Been Tested?

• Unit tests for argument parsing (tests/test_config.py): Verifies that --aws-cred-profile is correctly parsed and stored on the Config object, and that it defaults to None when not provided.
• Integration tests for precedence (tests/test_main.py::TestCredProfilePrecedence): Exercises the full generate_config() flow with a real config file, environment variables, and CLI arguments to verify the override chain:
  • CLI flag overrides config file value
  • CLI flag overrides environment variable
  • Environment variable overrides config file when no CLI flag is set
  • Config file value is used when neither CLI flag nor environment variable is set
• Existing tests updated to include the new aws_cred_profile argument in mocked Namespace objects so they continue to pass.
• All existing tests pass without modification.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[epierce]

Looks good - thanks!