Create PULL_REQUEST_TEMPLATE.md

[gracepotma]

Really it's a check-list more than a template.

This is largely in response to three things:

1. Folks working on UI changes often don't even know about our 3.0 Styleguide (which is creating bugs / inconsistent UI later on), and they also don't know about our widget directory
2. Folks often don't include the ticket link or an image of what they've changed
3. Folks will need to be more aware of tests as we increasingly include the E2E tests throughout the patient chart

[gracepotma]

(FYI @ebambo - feel free to add suggestions here)

[ebambo]

@gracepotma thank you for starting this, I think this makes sense and for now I have nothing to add.

[manuelroemer]

Sounds good to me!

One thing I'd like to throw into the ring is that we could also consider adding an explicit template structure like the following (just an example, can be entirely modified to anything really) while we are at it:

## Requirements

- [ ] My work conforms to the [**OpenMRS 3.0 Styleguide**](https://om.rs/styleguide).
- [ ] I checked for feature overlap with [**existing widgets**](https://om.rs/directory).


## Summary

<!--
Required.
Please describe what problems your PR addresses.
-->


## Screenshots

*None.*
<!--
Optional.
If possible, please insert any screenshots/videos of your changes here.
Don't forget to remove the *None.* above if you do fill this section.
-->


## Related Issue

*None.*
<!--
Optional.
If present, please link any related issue here, e.g. "https://issues.openmrs.org/browse/123").
Don't forget to remove the *None.* above if you do fill this section.
-->


## Other

*None.*
<!--
Optional.
Anything else that isn't covered by one of the sections above.
Don't forget to remove the *None.* above if you do fill this section.
-->

When I'm personally creating a new PR I prefer explicit templates like these because I don't have to spend time on creating a custom structure capturing all the requirements (description, screenshots, issues, etc.) and can just focus on "filling stuff in". It further makes all PRs have the same structure (which is a plus in my eyes).

But again, that's just a consideration. If you don't want to go with a full template like the above, the one that you currently have is more than enough and will do its job in guiding people as to what's required for a PR.

[manuelroemer]

About the tests: Imo we could skip this since we already have the pre-commit hooks and GitHub Actions pipeline for running the tests and failing the PR when something is wrong in that area. Also, I already had situations where the tests run fine locally and then fail in the pipelines. -> They should be the "source of truth" for tests anyway.

Maybe we could replace it with a hint about how to format the code? That's something that new contributors probably don't know about and which ultimately fails the pipelines during the linting stage. We could then even describe how to do that (i.e. run yarn prettier in the monorepos before creating the PR).

[FlorianRappl]

Why are these comments? Why not have a list of checkboxes that need to be checked when submitting?

See https://raw.githubusercontent.com/smapiot/piral/develop/.github/PULL_REQUEST_TEMPLATE.md for an example.

[FlorianRappl]

If we introduce PR templates then I'd strongly suggest pushing them to every repository.