Allow the browser-compat frontmatter value to be an array

[sideshowbarker]

We currently have some existing documents that use multiple {{Compat(...)}} macros within the same document — because without the browser-compat frontmatter key being allowed to contain an array, there’s no other way to have multiple BCD tables in the same document except by putting multiple {{Compat(...)}} macros in the document.

So, allowing the browser-compat value to contain an array eliminates the need for authors to put multiple {{Compat(...)}} macros in a document.

And reducing the need for authors to use the {{Compat(...)}} macro at all is also in line with our general de-macro-ization plans — in that it takes us a big step closer to completely eliminating the {{Compat}} macro altogether.

---

Part of the context for this change is that #5347 (reply in thread) has persuaded me that it would be a good idea for us to move wholly over to just using the browser-compat and spec-urls macros, and never using the {{Specifications}} and {{Compat}} macros.

The specific parts of #5347 (reply in thread) I found persuasive were:

Macros with arguments

...
…my preferences are toward:

1. Providing fewer ways to author things. Either the key is the only way it's done, or there ought be more unified way of richly citing/embedding non-MDN content.
2. Not committing to Kumascript-isms in Markdown.

In general, I'd really like to get away from macros as a way of embedding stuff in Markdown and it didn't feel like it was in scope for this discussion. That said, I'd like us to explore alternatives to Kumascript macro syntax, particularly the bits that are most unlike Markdown (in this case, arguments).

[github-actions]

This pull request has merge conflicts that must be resolved before we can merge this.

[caugner]

Closing in favor of #6464.