Add "Changelog" and "Migration Guide" to PR template (#4143)

# Objective

Context: [Discord Discussion](https://discord.com/channels/691052431525675048/745355529777315850/950532143325519902)

Improve the PR template by adding "Changelog" and "Migration Guide" sections. These sections should hopefully help speed up the review/merge process, as well as help make release notes and migration guides.

## Solution

Added the "Changelog" section template which suggests listing out the changes of the PR. This also acts as a sort of tl;dr for reviewers (especially for larger PRs).

Added the "Migration Guide" section template which suggests describing how a user might need to migrate their codebase to account for the changes by the PR. This also helps authors/contributors keep the end-user in mind when adding or changing the API.

Both sections are optional— an author does not _need_ to fill these out. Hopefully they will, though, as it provides a handful of really great benefits.

Co-authored-by: MrGVSV <49806985+MrGVSV@users.noreply.github.com>

.github/pull_request_template.md

@@ -6,3 +6,22 @@
 ## Solution
 
 - Describe the solution used to achieve the objective above.
+
+---
+
+## Changelog
+
+> This section is optional. If this was a trivial fix, or has no externally-visible impact, feel free to skip this section.
+
+- What changed as a result of this PR?
+- If applicable, organize changes under "Added", "Changed", or "Fixed" sub-headings
+- Stick to one or two sentences. If more detail is needed for a particular change, consider adding it to the "Solution" section
+  - If you can't summarize the work, your change may be unreasonably large / unrelated. Consider splitting your PR to make it easier to review and merge!
+
+## Migration Guide
+
+> This section is optional
+
+- If this PR is a breaking change (relative to the last release of Bevy), describe how a user might need to migrate their code to support these changes
+- Simply adding new functionality is not a breaking change.
+- Fixing behavior that was definitely a bug, rather than a questionable design choice is not a breaking change.