feat(PR/issues): Improve templating and automation

[ix-56h]

Subject

We needs to add a more templates for Issues and PRs.

---

Issue Templates

• bug (docs: add GitHub Issue Form for bug reports #403)
• feature/improvement (docs: add GitHub Issue Form for feature requests #404)
• refactor (maybe we can merge it with the feature one)

---

PR Template

name: Pull Request
about: Propose a change to the project
title: 'feat: Brief, descriptive title of your changes'
labels: ''
assignees: ''

# Description

Please provide a clear and concise description of the changes you've made. Explain the "why" behind this pull request.
Related Issue

<!--
Link to the issue that this PR addresses.
Use keywords like "Closes", "Fixes", or "Resolves" to automatically close the issue when this PR is merged.
Example: Closes #123
-->

Closes #

# Type of Change

Please check the options that apply to your PR.

    [ ] Bug fix (a non-breaking change that fixes an issue)

    [ ] New feature (a non-breaking change that adds functionality)

    [ ] Breaking change (a fix or feature that would cause existing functionality to not work as expected)

    [ ] Documentation update

    [ ] Chore (a change to the build process or auxiliary tools and libraries)

    [ ] Style (a change that does not affect the meaning of the code - white-space, formatting, etc.)

    [ ] Refactor (a code change that neither fixes a bug nor adds a feature)

    [ ] Test (adding missing tests or correcting existing tests)

# Author's Checklist

Please go through this checklist before you request a review.
- [ ] 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.
- [ ] Any dependent changes have been merged and published in downstream modules.

# Screenshots / Recordings (if applicable)

Please add screenshots or a screen recording to demonstrate the changes, especially for UI-related work.

## Before

...

## After	

...

# Notes for Reviewers

Is there anything specific you want the reviewers to focus on? Any potential areas of concern or questions you have?

[cyclotruc]

I agree with that, here's what I imagine:

Have two states for issues:
Discussing or Ready (as in ready to work on)
(name can be discussed)

Discussing is a state where we still need to figure out the details of the feature and the implementation strategy

The only way to switch an Issue to the Ready state is to have produced a specification document for the future PR

Ready means the issue is ready to be picked up and worked on (assigned)

That being said, I don't believe those rules should be enforced, the dev team is still small and we can afford the flexibility of sometimes bypassing this workflow, when it's reasonable (a 1 line hotfix shouldn't require to go through tons of paperwork, official maintainers should be able to push an urgent fix they are confident about without needing review, etc...)

[ix-56h]

What about branch naming patterns to ease the PR/Issue tracking ? @cyclotruc

1. {issue_id}_{feat/bug/refactor}_{short description}
2. {issue_id}_{short description}

[ix-56h]

#395 will add PR validation