Change link/anchor styling to use `text-decoration`, `text-decoration-color`, `text-underline-offset`.

Looking to tackle some low-hanging fruit! Closes #636.

[Link to deploy preview](https://deploy-preview-967--just-the-docs.netlify.app/).

Old behaviour:

<img width="582" alt="Screen Shot 2022-09-16 at 11 56 26 AM" src="https://user-images.githubusercontent.com/14893287/190711440-8e56c3a2-250f-4121-8c57-8e6e20c4ae07.png">

New behaviour:

<img width="546" alt="Screen Shot 2022-09-16 at 11 56 19 AM" src="https://user-images.githubusercontent.com/14893287/190711520-2cc7fd4d-d449-4e14-9e75-96545f9f578d.png">


Some notes:

- the only visible change should be minor differences in the thickness of the line (browser defaults) + how underhangs (ex a "g") interact with the line
- color-wise, this is a no-op :) 
- I added an offset to mimic the behaviour of `background-size: 1px 1px;`

Let me know what we think!

This is a bite-sized PR that fixes #681. It adds a very minimal styling set to `blockquote` that can be easily overridden by a user.

The [markdown kitchen sink](https://deploy-preview-965--just-the-docs.netlify.app/docs/index-test/) has the example described in the issue:

<img width="772" alt="Screen Shot 2022-09-15 at 5 49 44 PM" src="https://user-images.githubusercontent.com/14893287/190533247-60ddaba3-85b2-4c03-b520-a67f6b047345.png">


Note that it differs from GFM/GitHub's renderer:

> This is a blockquote!

I'm not sure if the intention is to bring it to one-to-one parity. If that's the case, I can dim the text color and make the sidebar thicker.

This is a catch-all PR that modernizes and updates our Stylelint config, and resolves all open issues. This is a pretty big change - so I want to update all of our related dependencies in lockstep.

In particular, this PR

- [x] updates stylelint to `v14`
- [x] adds in the standard stylelint config for SCSS (`stylelint-config-standard-scss`)
- [x] swaps out `stylelint-config-prettier` for `stylelint-config-prettier-scss`
- [x] ~~properly update `@primer`-related plugins:~~ completely remove `primer` from our configuration
- [x] autofix, manually resolve, or disable all newly-introduced lint errors; **I've avoided manually resolving errors that would be a behavioural change**
- [x] re-runs `npm run format`

See the "next steps" section on some extra thoughts on disabling errors.

(implicitly, I'm also using node 16/the new package-lock format).

### disabling rules and next steps

I've introduced several new disabled rules. Let me quickly explain what's going on; there are two categories of rules I've disabled:

1. rules that were temporary disables; they were frequent enough that I couldn't manually resolve them, but should be simple. **I plan on opening issues to re-enable each of these rules**, just after this PR
    - `declaration-block-no-redundant-longhand-properties`: this is just tedious and error-prone
    - `no-descending-specificity`: this one is tricky since it could have impacts on the cascade (though that seems unlikely)
    - `scss/no-global-function-names`: I think we need to [import map and then use `map.get`](https://stackoverflow.com/questions/64210390/sass-map-get-doesnt-work-map-get-does-what-gives), but I'll leave this as out of scope for now
2. rules that are long-term disables; due to the SASS-based nature of our theme, I think we'll keep these in limbo
    - `alpha-value-notation` causes problems with SASS using the `modern` syntax - literals like `50%` are not properly interpolated, and they cause formatting issues on the site
    - `color-function-notation` also causes problems with SASS, but in this case the `modern` syntax breaks SASS compilation; we're not alone (see this [SO post](https://stackoverflow.com/questions/71805735/error-function-rgb-is-missing-argument-green-in-sass)). 

In addition, we have many inline `stylelint-disable` comments. I'd open a separate issue to audit them, especially since I think some disables are unnecessary.

### on Primer 

**note: there hasn't been much other discussion, so I'm going to remove primer's stylelint config.**

If I do add `@primer/stylelint-config`, I get *a ton* of errors about now using `@primer`'s in-built SCSS variables. I imagine that we probably won't want to use these presets (though I could be wrong). In that case, I think we could either:

1. disable all of those rules
4. not use `@primer/stylelint-config`, since we're not actually using primer, and shift back to the standard SCSS config provided by Stylelint

~~Any thoughts here? I also don't have the original context as to why we do use the primer rules, perhaps @pmarsceill can chime in?~~

I have a site whose content is written in AsciiDoc, using the [jekyll-asciidoc][] plugin.

Just the Docs works great, but there are just two minor styling glitches I've noticed:

The first is that Just the Docs' CSS doesn't understand the code block markup jekyll-asciidoc produces.  It's not too different though, so it's very easily fixed.

The second is that jekyll-asciidoc generates `div.sect(𝑛 − 1)` elements around headings of type `h𝑛`, that enclose all the heading and all the content after it until the next heading of greater or equal rank.

This means that headings are _always_ first children in AsciiDoc output, which meant the wrong margins were applied to most headings. To fix this, we need to only reduce the margin of first-child headings nested directly below the .main-content element, and headings nested directly below AsciiDoc `.sect𝑛` elements that are themselves first children.

With these two small changes, my site looks perfect, and the styles look exactly the same as on Just the Docs' own documentation.

[jekyll-asciidoc]: https://github.com/asciidoctor/jekyll-asciidoc