Added a missing `{: .no_toc }`, to avoid a 3rd-level item in the displayed TOC at the top of the page.

99% certain we don't use this file;

- [script](https://github.com/just-the-docs/just-the-docs/search?q=script) has no non-`<script>`/doc uses
- [build](https://github.com/just-the-docs/just-the-docs/search?q=build) has no mentions
- we don't need to manually build / package the gem anymore

Bumps [stylelint](https://github.com/stylelint/stylelint) from 14.10.0 to 14.11.0.
- [Release notes](https://github.com/stylelint/stylelint/releases)
- [Changelog](https://github.com/stylelint/stylelint/blob/main/CHANGELOG.md)
- [Commits](https://github.com/stylelint/stylelint/compare/14.10.0...14.11.0

)

---
updated-dependencies:
- dependency-name: stylelint
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Short and sweet PR that addresses the follow-up in #909: enabling `mermaid` on our docs site, but making it clear that users still need to opt-in to use it. I've also added an example in-action.

To test: [see the Netlify deploy](https://deploy-preview-935--just-the-docs.netlify.app/docs/ui-components/code/#mermaid-diagram-code-blocks).

Bumps [stylelint-config-standard-scss](https://github.com/stylelint-scss/stylelint-config-standard-scss) from 3.0.0 to 5.0.0.
- [Release notes](https://github.com/stylelint-scss/stylelint-config-standard-scss/releases)
- [Changelog](https://github.com/stylelint-scss/stylelint-config-standard-scss/blob/main/CHANGELOG.md)
- [Commits](https://github.com/stylelint-scss/stylelint-config-standard-scss/compare/v3.0.0...v5.0.0

)

---
updated-dependencies:
- dependency-name: stylelint-config-standard-scss
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Matt Wang <matt@matthewwang.me>

Bumps [stylelint](https://github.com/stylelint/stylelint) from 14.9.1 to 14.10.0.
- [Release notes](https://github.com/stylelint/stylelint/releases)
- [Changelog](https://github.com/stylelint/stylelint/blob/main/CHANGELOG.md)
- [Commits](https://github.com/stylelint/stylelint/compare/14.9.1...14.10.0

)

---
updated-dependencies:
- dependency-name: stylelint
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

A couple of changes to prep for v0.4.0-rc1:

- bump the version
- add myself to the authors + email (this is primarily so that Patrick doesn't get siloed as the only maintainer; if you'd like to be added @just-the-docs/maintainers, let me know!)
- adds some more metadata ([gemspec docs](https://guides.rubygems.org/specification-reference/#metadata))
- updated the path to also include the CHANGELOG and favicon in the gem bundle

Version 0.4.0.rc1 - release PR

`mermaid`: refactor config to use `mermaid_config.js` include, only require `mermaid.version` in `_config.yml` (#909)

This PR has a bit of scope creep! This PR now:

- changes the mermaid opt-in logic to only check for the existence of a `mermaid` key instead of `mermaid != false`: this resolves the follow-up in #857
- changes the behaviour of mermaid configuration
    - instead of using `mermaid_init.html` with default settings, makes the include `mermaid_config.js`
    - the include is loaded directly into the contents of `mermaid_initialize`
    - by default, it is an empty object (i.e. `{}`), triggering the defaults
- updates docs
- adds an example to the markdown kitchen sink  

It does significantly change the interface provided in #857, and I apologize for the confusion. However, given the discussion in this PR, I think it's the best move forward!

See commit https://github.com/just-the-docs/just-the-docs/pull/578/commits/1fd4e4663d55f8686b06c1bf59e0a5a5bf08bae3

The nav scroll feature had stopped working (altogether),
due to the change from absolute to relative urls.

This update uses the document location pathname as the `href`.
It appears to work locally.

Enumerate Combination PRs

Some items are already listed separately, and some have no PRs.

Closes #899 (or at least, the immediate concern).

Fix #734.

- Remove `white-space: nowrap;` in `_sass/content.scss`.
- Add an example testing wrapping in`docs/index-test.md`.

Fixes a problem where multiple labels right after a heading are vertically misaligned.

Closes #751.

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?~~

- add an extra filter to children-list to fix #854
- strengthen condition for assignment to first_level_url

Tested with Jekyll 3.9.2 and 4.2.2

Note: Jekyll 3.9.2 doesn't support `| where: "grand_parent:  nil"`

This is a PR with three key changes:

1. Consolidate two identical CI files, `ci.yml` and `ci-master.yml` into one file
2. Consolidate two almost-identical jobs (`jekyll-build-*`) into one job with a strategy matrix
3. Update various dependencies/platforms
    * Node: `12.x` -> `16.x` (only in CI); `12.x` has been EOL for a while
    * Ruby: `2.6` -> `2.7`; `2.6` just reached EOL
    * `actions/checkout` -> `v2` -> `v3`
    * switches `jekyll/builder` to `jekyll/jekyll`, since we don't actually use any of the features in `jekyll/builder`

## on our CI philosophy

In working on this, I have a couple of questions:

1. We don't actually use our `Dockerfile` that we provide. Does this make sense? Should we be running CI with this instead?
2. Is there a specific reason that we're using `jekyll/jekyll`? Notably, this isn't an official package, but a community-driven one. Does it match what's used by GitHub Pages?
3. Do we have to use any docker image at all? For example, what if we just rely on the `setup-ruby` action?
    * one advantage of this is that it's much easier for us to test across multiple OS versions; we just need to have a strategy matrix for OS and do windows, macos, ubuntu, etc.
    * another advantage is that we can easily test different ruby versions in conjunction with different jekyll versions

Eventually, I would like to see us test across:

* different Jekyll versions
* different OSes
* different Ruby versions

but perhaps that might be too aggressive. Happy for any feedback on this PR or those questions!

without overflow-x: auto; a very long line of code will overflow the box and look awkward


Co-authored-by: Matt Wang <matt@matthewwang.me>