1 feature refactor the repository to make it more robust and easier to work with

[Colin23]

🚀 Pull Request

🔗 Linked Issue

Closes #1

📝 Description

🛠️ Changes Made

• Add a .editorconfig file
• Add a .gitignore file
• Add a README file
• Extract generic logic from the commit-msg script and create separate, self-contained util scripts for that
• Make the commit-msg script more robust and easier to configure
• Change the setup-hooks.sh scripts name to setup-hooks to be shell independent and consistent with the other scripts
• Add various comments

🧪 Testing

• Unit tests added/updated -> I thought about adding automated unit tests with [Bats](https://github.com/bats-core/bats-core), but the effort is not really worth it in my opinion.
• Integration tests added/updated -> The only thing where that would make sense is to test the GitHub API. I didn't feel like this needed integration tests. Also, the effort would be similar to adding Unit tests, which is just not necessary imo
• Tested manually
  I tested everything manually and also set up the conventional commits for this repo on my machine (hence the .zflbs file in the .gitignore).

📸 Screenshots (if applicable)

🔍 Additional Notes

The logic of everything should be unchanged. Arguable the two changes in functionality are that

1. Its possible to pass an argument to the script when running it directly e.g. ./setup-hooks hooks that overrides the default path to the hooks directory. This makes local development in this repo easier. Since we will usually use this repo as a submodule, this change is barely a feature that will be used often.
2. ANSI coloring will be used per default for everything. If tput is installed, this will be used instead. I didn't implement a case where the terminal doesn't support ANSI nor tput. There was so such fallback in the original implementation anyways, if we are keen on having that, we could add it later.

✅ Checklist

• I have read the contributing guidelines
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

👥 Reviewer Checklist

• The code change is focused and makes sense
• The code adheres to our established coding standards
• The changes are adequately tested
• The documentation is updated to reflect the changes (if necessary)

---

💖 Thank you for contributing to Zufall! 💖