Migrate Danger from GitHub Actions + ESP-IDF project

[tomassebestik]

Summary of changes

• Framework Migration: The existing framework has been extracted from the espressif/github-actions repository.
• Configurable Rule Parameters: Rule parameters can now be configured in the target workflow using the with: section.
• Codebase Tests: Added comprehensive tests to cover the entire codebase.
• Project Settings: As a separate project, we can now implement common project settings such as Prettier, ESLint, Jest, a Contributions Guide, and an issue tracker.
• Documentation Overhaul: Updated documentation, with README now split into smaller files. We've added extensive documentation for each rule, similar to GitLab's Shared-CI-DangerJS.
• New Rule - Source Branch Check: Introduced a rule for checking the correctness of the source branch name.
• GitHub Action CI Job Trace Log: The trace log now includes a table with configuration parameters and the exit state of each individual rule, same as in GitLab's Shared-CI-DangerJS.

Updated rules

• Description rule: Now have configurable ignored sections.
• Commit Messages rule: Implements conventional commits, aligned with GitLab's Shared-CI-DangerJS and the default of Conventional-Precommit-Linter.
• Number of Commits rule: Introduces a configurable threshold for warning/info type of Danger issue.
• Source Branch rule: New in GH Danger - Ensures the source branch name is correct.

Output instructions

• Review and Merge Process: The process is now dynamically presented (based on whether the GH project is a mirror) in a collapsible section.
• Danger Instructions: The explanation of how Danger works and how to fix issues is now dynamic and presented in a collapsible section.
• Extended Info for GitLab Mirrors: If the GitHub project is solely a GitLab mirror, additional information is provided about the review and merge process.
• Contributors Guide Link: Option to enable a link to the project's Contributors Guide in the Danger comment.
• Contributor License Agreement (CLA) Link: Option to include a link to the project's Contributor License Agreement in the Danger comment.

Styles

Tested

• test project: ci: test workflow for shared-github-danger test-project-bot#15
• see also Danger comment in this PR

Related

• RDT-601
• RDT-573

Next steps

• add deprecation warning to old version of Danger GH in github-actions repo; it will be removed 03/2024 (change(danger-github): add deprecated warning message to action output github-actions#57)
• remove Danger GH code from esp-idf project, replace by single workflow file; maintain all in this project

[github-actions]

	Warnings
⚠️	Please consider squashing your 10 commits (simplifying branch history).

	Messages
📖	This PR seems to be quite large (total lines of code: 2748), you might consider splitting it into smaller PRs

👋 Hello tomassebestik, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Resolve all warnings (⚠️ ) before requesting a review from human reviewers - they will appreciate it.
- Addressing info messages (📖) is strongly recommended; they're less critical but valuable.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests.

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
4. If the change is approved and passes the tests it is merged into the default branch.

Generated by 🚫 dangerJS against b595088

[tomassebestik]

@kumekay @dobairoland @alekseiapa PTAL ... it's very similar to Shared Danger Gitlab now. No need for in-depth code review logic, the code has full test coverage and has been tested in an external repo. Split to commits in logic sections. Many thanks, guys!

[dobairoland]

LGTM in general. I didn't do a detailed review.

[kumekay]

@tomassebestik I made a relatively quick review, but nothing catches my eye, looks good, thank you