Make CONTRIBUTING.md

[stan-dot]

From discussion with @DiamondJoseph ; there are non-trivial acceptance criteria to PRs that could be more explicit.

• does device connect - on one beamline, or all?
• when do we allow 'skip_device' in a PR?
  should PR code correspond to the beamline reality at merge OR to the model of beamline reality and the exact details could be worked in a separate PR?

[stan-dot]

current 'contributing' documentation is not as plain to see and does not cover those scenarios
https://diamondlightsource.github.io/dodal/main/how-to/contribute.html

[callumforrester]

While contributing guidelines are useful I think we should be careful.

Devices may fail to connect due to temporary beamline network issues, shutdowns, power cuts, or just being occasional-use. None of these should block a Github PR from being merged. Between these I do not think there will ever be a single instant where every device on device beamline connects, so there's little point in requiring that.

beamline reality at merge OR to the model of beamline reality and the exact details could be worked in a separate PR?

This one harder but personally I'm against formalizing this too. @stan-dot I think the docs you actually want are here. We are trialling the approved reviewer system in the hope that these kinds of decisions will spread culturally rather than formally. That means the people in the review team have a lot of weight in the decision. Personally I would bias myself towards beamline reality at merge.