markdownlint on github issue and pr templates

.github/ISSUE_TEMPLATE/bug_report.md

@@ -12,6 +12,7 @@ A clear and concise description of what the bug is.
 
 **To Reproduce**
 Steps to reproduce the behavior:
+
 1. Go to '...'
 2. Click on '....'
 3. Scroll down to '....'

.github/ISSUE_TEMPLATE/question.md

@@ -7,6 +7,6 @@ assignees: ''
 
 ---
 
-_Note:_ Questions for the SSVC team can be asked here in the form of an issue. More general questions directed at the SSVC user community
+*Note:* Questions for the SSVC team can be asked here in the form of an issue. More general questions directed at the SSVC user community
 might be a better fit in the [Q&A](https://github.com/CERTCC/SSVC/discussions/categories/q-a) category of our
 [Discussions](https://github.com/CERTCC/SSVC/discussions) area.

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -4,7 +4,7 @@
   not just a reference to an issue number. PR titles are used in the commit log
   and release notes, so they need to convey meaning on their own.
 - Most pull requests should be in response to an issue, and ideally a PR will
-  resolve or close one or more issues. 
+  resolve or close one or more issues.
 - If a PR only partially resolves an issue,
   we suggest spawning one or more child issues from the main issue to identify what portion
   of the issue is resolved by the PR, and what work remains to be done.
@@ -13,5 +13,5 @@
 - Using bulleted lists with the issue id at the end lets github automatically
   link the issue and provide the title inline. E.g.: `- resolves #99999`
 - CoPilot summaries are welcome in the PR description, but please provide a brief
-description of the changes in your own words as well. CoPilot can be good at the _what_,
-but not so good at the _why_.
+description of the changes in your own words as well. CoPilot can be good at the *what*,
+but not so good at the *why*.