Docs: First draft of contribution guidelines

[JoshSanch]

With all of the new contributors coming in lately, I'd like to take this moment to introduce some contribution guidelines to help folks make PRs that will be easy to review and merge into the project.

My goal with this document is to have an accessible list of expectations that contributors can reference ahead of time and allowing for in-depth conversations on guidelines to occur within pull requests when they infrequently occur.

- Josh

[LivewireCB]

Consider adding a clear definition of variable naming conventions.
for example; using "myVar" instead of "MyVar" or "myvar"

[JoshSanch]

Candidate convention I'd like to add based on this commit:

- Hexadecimal literals used as arguments for asset functions should be represented using char literals when it would improve the readability of the code (i.e 0x504c4154 -> 'PLAT').

[JoshSanch]

I'm adding this line - it's a bit arbitrary but it closely aligns with Heavy Iron's naming standards so I'd like to follow that:

- When DWARF symbols are unavailable, ensure variables are named using camelCase and structs/classes are named using TitleCase, or snake_case if they exist only in an anonymous namespace.

[SquareMan]

Mostly lgtm.

Feel free to ignore my last comment if you disagree.

[JoshSanch]

Proposing to add:

- Avoid adding functions or data definitions that will need to be cleaned up and removed later for the sake of increasing matchingness in the short-term.

This is inspired by the existing _all_the_floats function, and proposed changes on #567. This is an artifact of the old build/match comparison tooling and is no longer necessary. It also adds clean-up work later for no long-term benefit.

[JoshSanch]

Going to merge for now - I invite anyone with any further thoughts to raise an issue or to start discussion in the community Discord.