Document our development and contributing guide

Done Criteria

There is an easily discoverable document that bootstraps someone on contributing, sets expectations of contributors/developers, and answers related frequently asked questions.

Why Important

Having a community of contributors is a key success criteria for Helia. I hypothesize that documentation here helps makes contributing more approachable/self-service.

Notes

I know we link to https://github.com/ipfs/community/blob/master/CONTRIBUTING_JS.md. It looks like that has some older stuff. I think we either need to update that doc inline, copy it and make updates, or create an addendum with Helia specifics and then link to https://github.com/ipfs/community/blob/master/CONTRIBUTING_JS.md. I expect we want our own place to add copy just so there is no friction to be documenting Helia-related things. I worry folks would shy away from touching https://github.com/ipfs/community/blob/master/CONTRIBUTING_JS.md because they don't know whereall it's linked from or because Helia specifics aren't relevant there.

Items that would want to see included:

[ ] Link to the release process/philosophy (https://github.com/ipfs/helia/issues/81)
[ ] Set clear expectations on how PRs are to be titled/written.
- For example, comments like https://github.com/ipfs/helia/pull/80#pullrequestreview-1374199712 shouldn't be needed, and when they are, they should just be a link to a doc section. (Although I do see some of that is covered in https://github.com/ipfs/community/blob/master/CONTRIBUTING_JS.md ).
[ ] Where can someone show up to engage with other contributors (e.g., chat, triage)
[ ] Where the inprogress and ondeck work is tracked (presumably linking to a Helia project board)
[ ] Expectation that PRs are linked to issues that provide rationale and justification for the work. (It should be clear to a reviewer "why are we doing this")
[ ] Include some of the verbiage that is copy/pasted various places like "Please be aware that all interactions related to this repo are subject to the IPFS Code of Conduct" or "Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions." We can then remove that copy/pated text.
[ ] How someone become a maintainer? (We can say that this process needs to be fully determined, but starts with showing making contributions and demonstrates good judgment)

ipfs / helia