Augment contributing docs

[wesharper]

Summary

While the package is well-written, easy to navigate, and well-documented for package consumers, the contributing docs could be augmented with additional details, tips, and tricks for people who want to become productive contributors more quickly.

Rationale

While the package is excellent, its feature set is lagging behind some competitors like Hasura. Ideally, documentation improvements would reduce the barrier to entry for the community to get involved and can help encourage more community PRs for patches and new features. Leaning on the community more can foster engagement and buy-in in the ecosystem and lead to a faster release cycle.

Additionally, while it's clear the maintenance team is dedicated to the success of the package, it also seems that the team is spread fairly thin. Delegating more development to the community will give the maintainers the ability to set high-level vision and architectural goals while improving overall throughput.

Design

• [x] add additional platform-agnostic details on getting up and running locally, with recommendations for spinning up local databases that play well with common workflows outside of pg_graphql maintenance
• [x] add guides for creating and validating net new tests, including tips on generating output snapshots for use in tests
• [x] add local development workflow recommendations, especially with tips on debugging and assessing changes locally
• [x] add a link to the contributing docs in the readme
• [ ] add a comprehensive releases and builds section so people know what to expect if they either want to do the work to create a release or, if they're willing to wait, what they should be looking for in the code to check the progress of the release (including in platforms like supabase)

Links to external resources are fine. The idea is not to rewrite docs for how to use cargo, rust, pgrx, postgres, etc. However, starting with the assumption that maintainers may be unfamiliar with one or more tools and pointing people in the right direction regarding the most important steps could improve ramp-up times.

Examples

• I have run queries locally and have manually validated the expected output, how can I quickly develop a snapshot of the outputs for use in tests?
• I have made some changes to the code, but I would like to validate some assumptions. How can I debug the changes? Is print statement debugging possible?
• I made a patch that got merged in. What needs to happen for me to be able to use it in supabase?

Drawbacks

• Good docs take time, time which puts other features on the back-burner.
• There are no guarantees that the docs will be used in any meaningful way.

Alternatives

• Do nothing, expect contributors to be savvy enough to get up and running on their own. This isn't unreasonable and should be a baseline expectation.

Unresolved Questions

• Are there common issues would-be contributors often encounter that prevents them from contributing?
• Are there other known documentation improvements that can be added?

[imor]

@wesharper there's a contributing guide which I've tried to expand in this PR. Hope this is useful, if not let me know and I can add more details.

[wesharper]

@imor that guide certainly saved my skin when I was getting up and running, but I do think more expansion would be useful for folks like me who are new to some aspects of the stack. The biggest win for me would have been common workflows, especially around debugging and sanity testing code in progress.

[imor]

@wesharper the new PR adds sections on how to do debug (basically it's debugging by logging, no breakpoints supported). It also adds a section on how tests work. What exactly do you find difficult that is missing from the guide? I can add relevant details to the sections you find lacking.

[wesharper]

Ah, so sorry about that, somehow I missed the debugging section in the diff. It definitely helps.

I marked off the items in the issue that I feel are addressed. The others are certainly not necessary and I won't be offended if this is closed without additional consideration (although I'll probably make a PR addressing the last item, just for ease of access).