docs: simplify crates README files and enforce PR-only workflow (#110)

* docs: simplify all crates README files

- Remove extensive code examples and detailed documentation
- Convert to minimal module introductions with core feature lists
- Direct users to main RustFS repository for comprehensive docs
- Updated 20 crate README files for consistency and brevity

Files updated:
- crates/rio/README.md (415→15 lines)
- crates/s3select-api/README.md (592→15 lines)
- crates/s3select-query/README.md (658→15 lines)
- crates/signer/README.md (407→15 lines)
- crates/utils/README.md (395→15 lines)
- crates/workers/README.md (463→15 lines)
- crates/zip/README.md (408→15 lines)

* docs: restore original headers in crates README files

- Add back RustFS logo image and CI badges
- Restore formatted headers and structured layout
- Keep simplified content with module introductions
- Maintain consistent documentation structure across all crates

All 20 crate README files now have proper headers while keeping
the simplified content that directs users to the main repository.

* rules: enforce PR-only workflow for main branch

- Strengthen rule that ALL changes must go through pull requests
- Explicitly forbid direct commits to main branch under any circumstances
- Add comprehensive PR requirements and enforcement guidelines
- Clarify that PRs are the ONLY way to merge to main branch
- Add requirement for PR approval before merging
- Include enforcement mechanisms for branch protection

.cursorrules

@@ -5,15 +5,18 @@
 ### 🚨 NEVER COMMIT DIRECTLY TO MASTER/MAIN BRANCH 🚨
 
 - **This is the most important rule - NEVER modify code directly on main or master branch**
+- **ALL CHANGES MUST GO THROUGH PULL REQUESTS - NO EXCEPTIONS**
 - **Always work on feature branches and use pull requests for all changes**
 - **Any direct commits to master/main branch are strictly forbidden**
+- **Pull requests are the ONLY way to merge code to main branch**
 - Before starting any development, always:
   1. `git checkout main` (switch to main branch)
   2. `git pull` (get latest changes)
   3. `git checkout -b feat/your-feature-name` (create and switch to feature branch)
   4. Make your changes on the feature branch
   5. Commit and push to the feature branch
-  6. Create a pull request for review
+  6. **Create a pull request for review - THIS IS MANDATORY**
+  7. **Wait for PR approval and merge through GitHub interface only**
 
 ## Project Overview
 
@@ -817,6 +820,7 @@ These rules should serve as guiding principles when developing the RustFS projec
 
 - **🚨 CRITICAL: NEVER modify code directly on main or master branch - THIS IS ABSOLUTELY FORBIDDEN 🚨**
 - **⚠️ ANY DIRECT COMMITS TO MASTER/MAIN WILL BE REJECTED AND MUST BE REVERTED IMMEDIATELY ⚠️**
+- **🔒 ALL CHANGES MUST GO THROUGH PULL REQUESTS - NO DIRECT COMMITS TO MAIN UNDER ANY CIRCUMSTANCES 🔒**
 - **Always work on feature branches - NO EXCEPTIONS**
 - Always check the .cursorrules file before starting to ensure you understand the project guidelines
 - **MANDATORY workflow for ALL changes:**
@@ -826,10 +830,20 @@ These rules should serve as guiding principles when developing the RustFS projec
    4. Make your changes ONLY on the feature branch
    5. Test thoroughly before committing
    6. Commit and push to the feature branch
-   7. Create a pull request for code review
+   7. **Create a pull request for code review - THIS IS THE ONLY WAY TO MERGE TO MAIN**
+   8. **Wait for PR approval before merging - NEVER merge your own PRs without review**
 - Use descriptive branch names following the pattern: `feat/feature-name`, `fix/issue-name`, `refactor/component-name`, etc.
 - **Double-check current branch before ANY commit: `git branch` to ensure you're NOT on main/master**
-- Ensure all changes are made on feature branches and merged through pull requests
+- **Pull Request Requirements:**
+  - All changes must be submitted via PR regardless of size or urgency
+  - PRs must include comprehensive description and testing information
+  - PRs must pass all CI/CD checks before merging
+  - PRs require at least one approval from code reviewers
+  - Even hotfixes and emergency changes must go through PR process
+- **Enforcement:**
+  - Main branch should be protected with branch protection rules
+  - Direct pushes to main should be blocked by repository settings
+  - Any accidental direct commits to main must be immediately reverted via PR
 
 #### Development Workflow