message: chore: Update pull request template
  Adding a commit summary section for future release automation. The `Category` section is important for release note categorization. `Notes` section is used in release notes to call attention for people upgrading. `BREAKING CHANGES` is added to show where it should go.
diff: -<!-- Thank you for your pull request, please provide a brief summary of what this introduces (mandatory). Please point out any code that may be non-obvious to reviewers by using comments. -->
  -
  -<!-- Make sure that you've linted your files, written and run unit tests, and filled out or updated documentation (README) -->
  +<!-- Thank you for your pull request, please provide a brief summary of what this introduces (mandatory). Please point out any code that may be non-obvious to reviewers by using in-code comments. -->
  ## Summary
  -<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
  +Fixes: #1234 <!-- For bug fixes, use "Fixes". For new features use "Resolves". This helps link a PR to an issue and will show up in release notes. -->
  +
  +<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? Anything in the Summary section will be attached to the squashed commit when this PR is merged. -->
  +
  +<!-- This is the category in the release notes. Common categories are Components, Infrastructure, and Documentation -->
  +![category](https://img.shields.io/badge/category-Components-blue)
  +
  +### Release Note
  +Optional release note message. Changelog and release summaries will contain a pull request title. This section will add additional notes under that title. This section is not a summary, but something extra to point out in release notes. An example might be calling out breaking changes in a labs component or minor visual changes that need visual regression updates. Remove this section if no additional release notes are required.
  +
  +### BREAKING CHANGES
  +Optional breaking changes message. If your PR includes breaking changes. It is extremely rare to put breaking changes outside a `prerelease/v*` branch. Anything in this section will show up in release notes. Remove this section if no breaking changes are present.
  +
  +---
  ## Checklist
  <!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->
  -- [ ] branch has been rebased on the latest master commit
  - [ ] tests are changed or added
  -- [ ] `yarn test` passes
  -- [ ] all (dev)dependencies that the module needs is added to its `package.json`
  -- [ ] code has been documented and, if applicable, usage described in README.md
  -- [ ] module has been added to `canvas-kit-react` and/or `canvas-kit-css` universal modules, if
  - applicable
  +- [ ] code has been documented
  - [ ] design approved final implementation
  - [ ] a11y approved final implementation
  -- [ ] code adheres to the [API & Pattern guidelines](../modules/docs/mdx/API_PATTERN_GUIDELINES.mdx)
  +- [ ] code adheres to the [API & Pattern guidelines](https://workday.github.io/canvas-kit/?path=/story/welcome-dev-docs-api-pattern-guidelines--page)
  ## Additional References
  