Fix typos in md files (sanity-io#1551)

* Fixed typos in `CONTRIBUTING` and the PR template

* Linted markdown files using the rules of markdownlint
[https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md)

.github/ISSUE_TEMPLATE/bug_report.md

@@ -15,6 +15,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/PULL_REQUEST_TEMPLATE.md

@@ -1,4 +1,4 @@
-<!-- Thank you for contributing to Sanity. Please read our [Code of Conduct](https://github.com/sanity-io/sanity/blob/next/CODE_OF_CONDUCT.md) and [Contributing Guidelines](/sanity-io/sanity/blob/next/CONTRIBUTING.md) before submitting a PR.
+<!-- Thank you for contributing to Sanity. Please read our [Code of Conduct](https://github.com/sanity-io/sanity/blob/next/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/sanity-io/sanity/blob/next/CONTRIBUTING.md) before submitting a PR.
 
 To help us review your Pull Request, please make sure you follow the steps and guidelines below.
 
@@ -30,7 +30,7 @@ Do not delete the instructional comments. -->
 
 **Note for release**
 
-<!-- Please include a high level summary of the changes this PR introduce. The intended audience is both editors and developers. If a new feature, remember to link to docs/blogpost, if bugfix please describe the bug in non-techincal terms (e.g. how a user/developer may have experienced it).
+<!-- Please include a high level summary of the changes this PR introduce. The intended audience is both editors and developers. If it's introducing a new feature, remember to link to docs/blogpost, if it's a bugfix, please describe the bug in non-technical terms (e.g. how a user/developer may have experienced it).
 For inspiration, check out the release notes from an earlier release: https://github.com/sanity-io/sanity/releases/tag/v0.142.0 -->
 
 **Checklist** 

CONTRIBUTING.md

@@ -2,14 +2,16 @@
 Want to file an issue? [Jump to _How to file an issue_ ⏬](#how-to-file-an-issue)
 
 # Contributing
+
 Contributions are always welcome, no matter how large or small.
 
 ## Getting started
+
 Before contributing, please read our [code of conduct](https://github.com/sanity-io/sanity/blob/master/CODE_OF_CONDUCT.md).
 
 Then make sure you have *Node.js version 4 or newer* and *npm version 5 or newer*.
 
-```
+```sh
 git clone [email protected]:sanity-io/sanity.git
 cd sanity
 npm install
@@ -23,48 +25,56 @@ npm start
 - Anything in the `next` branch is scheduled for the next release
 - To work on something new, create a descriptively named branch off of `next` (ie: feature/new-oauth2-scopes)
 - Commit to that branch locally and regularly push your work to the same named branch on the server.
-- Rebase your feature branch regularily against `next`. Make sure its even with `next` before merging.
+- Rebase your feature branch regularly against `next`. Make sure its even with `next` before merging.
 - Once its done, open a pull request to merge your feature branch into `next`
 - After someone else has reviewed and signed off on the pull request, you can merge it into `next`.
 - Everything except minor *trivial* changes should go through pull-requests. If you're unsure whether it's a trivial change or not, submit a pull request just to be sure.
 - Pull requests should be as ready as possible for merge. Unless stated otherwise, it should be safe to assume that:
-	- The changes/feature are reviewed and tested by you
-	- You think it's production ready
-	- The code is linted and the test suite is passing
+
+  - The changes/feature are reviewed and tested by you
+  - You think it's production ready
+  - The code is linted and the test suite is passing
+
 - It's fine to open a pull request to start a discussion / ask for help, but it should be stated clearly that it's not yet ready for merge.
 - When the `next`-branch is throughly tested and ready to be released (either as a minor or major version bump), it should be merged into master and bumped.
 - Critical fixes goes straight into master (preferably through a pull request)
 
 ## Merging
+
 Prefer squash + merge. If it makes sense to keep individual commits (e.g. different people has been working on the same feature), the pull request should be merged with the "Rebase + merge"-button. If possible, each individual commit message should be rewritten with the pull-request number in paranthesis, e.g. `[some-package] Fix stuff (#22)`
 
 ## Publishing official releases
+
 [**NOTE** Only publish _minor_ releases until Sanity passes the 1.0 mark]
 
 When `next` is ready for release, run `npm run publish` and select version. After a successful release, remember to rebase `next` against `master`.
 
 ## Publishing a hotfix release from `master`
-If we need to publish hotfix, a patch release should be done by running `npm run publish` from the project root, selecting "Patch" from the menu. Remember to rebase `next` against `master` after the release is completed.
+
+If we need to publish a hotfix, a patch release should be done by running `npm run publish` from the project root, selecting "Patch" from the menu. Remember to rebase `next` against `master` after the release is completed.
 
 ## Publishing _prerelease_ versions from `next`
+
 This is done by running `npm run publish` from the project root, selecting "Prerelease" from the menu and choosing a _Prerelease identifier_ (e.g. **alpha**, **beta** or **rc**). A prerelease can be tested in the studio by running e.g. `sanity upgrade --tag=beta --save-exact`
 
 ## Publishing _canary_ versions from feature branches
-This can be done at any time by anyone and is done by `npm run publish-canary`. This will publish with the commit hash from HEAD, and can be installed with `sanity upgrade --tag=canary --save-exact`
 
+This can be done at any time by anyone and is done by `npm run publish-canary`. This will publish with the commit hash from HEAD, and can be installed with `sanity upgrade --tag=canary --save-exact`
 
 # How to file an issue
 
 If you find a security vulnerability, do **NOT** open an issue. Email [email protected] instead.
 
 Any security issues should be submitted directly to [email protected]. In order to determine whether you are dealing with a security issue, ask yourself these two questions:
+
 - Can I access something that's not mine, or something I shouldn't have access to?
 - Can I disable something for other people?
+
 If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you're unsure, just email us at [email protected].
 
 ## How to report a bug
 
-When filing an issue, make sure to answer these five questions:
+When filing an issue, make sure to answer these six questions:
 
 - Which versions of Sanity are you using (`sanity versions`)?
 - What operating system are you using?
@@ -83,7 +93,7 @@ If you run into build issues, you might want to run `npm run init`, which will d
 
 # Testing
 
-```
+```sh
 npm test
 ```