Shorter PR template (#8571)

## Rational for this change

While we've had a PR template for a while, we've not been very good at
actually using it. This PR proposed a new shorter template, with
somewhat more focused direction and less text.

## What changes are included in this PR?

- New PR template.

## What APIs are changed? Are there any user-facing changes?

N/A

Signed-off-by: Adam Gutglick <adam@spiraldb.com>

Author: AdamGS

.github/pull_request_template.md

@@ -1,55 +1,23 @@
-<!--
-Thank you for submitting a pull request! We appreciate your time and effort.
-
-Please make sure to provide enough information so that we can review your pull
-request. The Summary and Testing sections below contain guidance on what to
-include.
--->
-
-## Summary
+## Rational for this change
 
 <!--
-If this PR is related to a tracked effort, please link to the relevant issue
-here (e.g., `Closes: #123`). Otherwise, feel free to ignore / delete this.
-
-In this section, please:
-
-1. Explain the rationale for this change.
-2. Summarize the changes included in this PR.
+Why are you proposing this change, and what is its impact. 
+Is it part of a long term effort, or a bigger change?
 
-A general rule of thumb is that larger PRs should have larger summaries. If
-there are a lot of changes, please help us review the code by explaining what
-was changed and why.
-
-If there is an issue or discussion attached, there is no need to duplicate all
-the details, but clarity is always preferred over brevity.
+If this PR is related to a tracked effort or an open issue, please link to the relevant issue.
 -->
 
-Closes: #000
+- Closes: #000
 
+## What changes are included in this PR?
 <!--
-## API Changes
-
-Uncomment this section if there are any user-facing changes.
-
-Consider whether the change affects users in one of the following ways:
-
-1. Breaks public APIs in some way.
-2. Changes the underlying behavior of one of the engine integrations.
-3. Should some documentation be updated to reflect this change?
-
-If a public API is changed in a breaking manner, make sure to add the
-appropriate label.
+No need to duplicate information from the previous section, but if you're touching many
+parts of the code base, its worth explicitly noting the important changes or how they are tested.
 -->
 
-## Testing
+## What APIs are changed? Are there any user-facing changes?
 
 <!--
-Please describe how this change was tested. Here are some common categories for
-testing in Vortex:
-
-1. Verifying existing behavior is maintained.
-2. Verifying new behavior and functionality works correctly.
-3. Serialization compatibility (backwards and forwards) should be maintained or
-   explicitly broken.
+Are there any user-facing changes that might require documentation updates
+Is any public API changed?
 -->