Consider using a language other than "js" for Syntax blocks

[Josh-Cena]

We are considering adopting different toolings on the content repo, for example, Prettier (for formatting) and ESLint (for enforcing some best practices).

I tried locally and got pretty decent results. However, one issue is syntax blocks. ESLint consistently chokes on some blocks, because they are not valid JS:

// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function
function name([param[, param,[..., param]]]) {
   [statements]
}

// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import
import { export1 , export2 as alias2 , [...] } from "module-name";

While we now discourage the use of BNF-style optional parameters, it's hard to make everything valid JS, considering things like ellipsis, placeholders, etc.

Should we use a non-JS language tag for syntax blocks? We can map them back to JS during rendering, so syntax highlighting on the website should not be a problem.

[teoli2003]

Yes, you are right: @wbamberg identified this problem too.

Given that Prism on MDN has an alias feature (syntax-highlighting.js, line 40) we should:

1. In Yari, add an alias to js: let's map a new jssyntax keyword to js. (See the potential PR for it: Add jssyntax as Prism alias for syntax boxes yari#6682)
2. Bulk edit the syntax boxes on MDN to use jssyntax instead of js. This is fairly easy.

At this point, we have no difference for the readers, no added complexity to Yari (the alias feature already exists), with only minimal changes to our page structure.

We can then:
3. Move forward to add ESLint/Prettier (configured to ignore jssyntax blocks), without impacting the syntax boxes and their pseudo-js.

cc/ @mdn/core-dev, @wbamberg, @Rumyra, @schalkneethling