PR workflow suggestions

There's no template here, so I'll just write them down. If something's already mentioned, please tell me so I can cross them out!

- It's common to see new contributors making PRs on their `master` branch, which prevents them from properly making any other PR in the future (especially with rebasing). I assume good faith that they're reading the docs, but they probably skipped it because they don't know how to keep track of git stuff (to know what branch they're on for example) or don't know the underlying logic behind it (probably just thinking it was unnecessary). I followed these steps closely when I was a new contributor, but if you're not familiar with it, then it's easy to forget. Maybe a kind admonition explaining why you should never skip the step of creating the branch can work, and show how to double-check your branch? Many people are new to `git` after all. (I myself learned `git` through these guidelines :D )
- When testing PRs, some people might be inclined to use the `gh checkout` feature over `git fetch`, which usually saves time since there's a copy-paste option right there. It's non-applicable for branches which don't have PRs, ofc, but most people are probably testing PRs directly. I don't know what the rules about that are, so it's worth mentioning what the guidelines are about it. (I don't download the artifacts generated by GitHub because I like to have more control over the branch, especially if I need to rebase it. I usually test PRs by merging them into a `custom_build` branch where I test several PRs at once in my real projects to see how they'll interact in `master` if they were merged. I also test my own PRs this way. It's usually unlikely that they'll collide. This saves me lots of build time since otherwise, branches are usually made from different versions of `master`, so I would have to rebuild everything otherwise. This isn't a common workflow used, though, so IDK how documentable this is.)
- The new contributor guidelines states that feature PRs are discouraged for new contributors which makes sense, of course (since many people come in usually just wanting to contribute the features they want even if it's not beneficial to the general population rather than working on bugs that benefit everyone in the long run), but there's not much guidance of what bugs they can reasonably fix (and what shouldn't be worked on without testing, figuring out the right solution etc.). `good first issue` probably used to be a good label, but now nothing falls under that category (other than godotengine/godot#100000 :p ). It's not obvious that there's "Up for grabs" sections in the projects. A mention of that would be useful.
- Idk if it's mentioned, but it should be clarified that there should be some approval or discussion on proposals, even if it's your own (especially), before making a feature PR, lest your PR has to be closed, due to it being the wrong solution or not a general solution, or ignored forever (again because it's not favored by the general contributor population).

If I think of something else, I'll edit this accordingly.

Start by locating the new contributor guidelines, PR workflow guidance, and any sections covering branches, testing PRs, bug selection, and feature proposals. Review the existing advice before consolidating the suggestions, and consider the work done when the relevant guidance clearly covers these workflows without duplicating existing documentation.

Written by the indexing model from the issue text.