Figure out contribution guidelines

[NotAShelf]

Hey @Kirottu, I hope you don't mind me taking initiative as a collaborator.

I wanted to propose deciding on contribution guidelines for a few topics to help prune open PRs, or guide them towards correctness a little bit further in the name of maintenance. Namely, I would like to figure out

1. Commit format; we are mixing scoped commits and conventional commits right now, which is inconsistent
2. Code style; comments, acceptable idioms, etc.
3. What is acceptable in the core, what should be a plugin
4. Formatting guidelines; there isn't a rustfmt configuration, so different formatters might conflict.

Perhaps those can be covered in a single contributing.md and linked in the README or/and PR templates.

[Kirottu]

First of all it's nice to have help, especially with the massive backlog of stuff to do I've created for myself. So no problems there.

Also I believe there is a very barebones contributor's guideline in the org repo, but as said it is very barebones and not linked to in the project repo.

As for your points:

1. Scoped commits do sound like a good idea in general, just needs guidelines as stated.

2. Code style is a bit tougher, I do agree it should be consistent at least per crate but right now I have no input on what it should be or how it should be codified.

3. Another question I thought of with feat: add input state persistence #213, as persisting input doesn't really feel like something that belongs in the core program. The plugin API however does not support what input persistency would need, nor do I think it necessarily even should in its current form.

   Maybe the solution would be another "utility" API or a more fundamental redesign of the plugin API to allow for much complex behavior without bloating up the interface for normal plugins.

4. I've always just used standard rustfmt settings, and they seem perfectly fine to me at least. Just needs enforcing.