Added devconfig-validator and comment handler

[boblodgett]

Description

The DevConfig Validator is a GitHub workflow that automatically checks if a DevConfig file is needed for your PR and helps you create one if necessary. The workflow detects changes to core and service files and determines if a DevConfig file is required.

Workflow

1. When you create or update a PR, the validator checks if a DevConfig file exists.
2. If no DevConfig file is found but changes require one, the validator adds a comment to your PR with a preview of the suggested DevConfig.
3. You can then add the DevConfig file using one of the provided commands.

Commands

The DevConfig Validator supports the following commands that you can use in PR comments:

• /add-devconfig: Adds the preview DevConfig file to your PR. You can also provide your own JSON to customize the DevConfig.
• /delete-devconfig: Removes the DevConfig file from your PR.
• /amend-devconfig: Updates the existing DevConfig file with new JSON content.

Example usage:

/add-devconfig
```json
{
  "core": {
    "changeLogMessages": [
      "Your custom changelog message"
    ],
    "type": "patch",
    "updateMinimum": true
  }
}
```

Test PR showing interaction: https://github.com/aws/aws-sdk-net-staging-dev/pull/1

Associated PR for the offline tool referenced by the validator: #3811

TODO:

• Need to verify how this works with forks
• Should exclude *.sln files from the auto service discovery checks.
• Possibly better initial changelog message creation.
• May not want to trigger the initial validator on edit of a PR. It could be manually retrigged instead.

Motivation and Context

Need a way for developers (Internal/External) to know devconfig files are needed and to give the best starting point for getting those devconfig files added easily to their PRs.

Testing

Test PR showing interaction: https://github.com/aws/aws-sdk-net-staging-dev/pull/1

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 README document
• I have added tests to cover my changes
• All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license

[normj]

You might want to give guidance on when to use patch versus minor.

[normj]

Give an example of when they might want to set this to true.

[normj]

Call out the bat file for windows or ./buildtools/add-devconfig.sh for mac/linux

[normj]

I might be missing something but depending on when the contributor branched from development there might be dev config files for other unshipped PRs in the forked branch. Would the workflow say all is good because there is a dev config in the folder even though it is unrelated to what the PR does?

[normj]

Should this workflow be skipped if the target is anything other then development or the V3 development? What I'm thinking is the PR is an incremental work for a feature branch a dev config is not required.