[meta] Add a Prior Art section to the RFC template

[hgoldstein]

Like most engineering, language design heavily benefits from looking at prior art, and the vast majority of language features have prior art in a widely used programming language:

• Having similar features look and behave similarly helps widen the pit of success: it's good that a while loop in Luau and one in JavaScript work roughly the same.
• You can dodge known pitfalls with commonly implemented features: as of this writing we are using other implementations of classes to prove out the design for classes in Luau.
• Other languages with extensive RFC processes can provide hints and reasoning for direction on our RFCs, for example the FAQ about why Javascript uses the # sigil to mean private.

This can also apply to prior art for library functions. If we're adding a new math function, do other languages standard libraries have the same functions? The same constants?

This is worth adding a section to push all RFC writers in the right direction.

[InfraredGodYT]

I never thought about an approach like this, but I could see it being widely used across future RFCs.

[bradsharp]

Supportive of us adding this. We should also include a point about the existing language design being a key piece of prior art. For example if we introduced a new global called array then you would create one through array.create for consistency with table.create or coroutine.create rather than calling it something like array.init.

[nnullcolumn]

are there any examples of other projects which have this as part of their RFC process? /j

i am in support of this idea, but i think we could probably deliberate a bit over the organization and reading flow

[nnullcolumn]

i think "supporting features" should be defined better or replaced with "related features" so that people are less likely to take mental shortcuts (maybe?)

[nnullcolumn]

naming, syntax, and semantics

i would replace with "naming, syntax, or semantics" or "naming, syntax, and/or semantics"

[nnullcolumn]

"How do they compare and contrast to this design" might invite very shallow comparisons especially so late into the body. Maybe it'd be better to include this section below Motivation, above Design, and rework the wording to something along the lines of "What design considerations are unique to luau or that feature which are different here?" That way we flow from Motivation -> Similar Designs + Declaring Unique Constraints -> Design

[nnullcolumn]

Do other programming languages

I'd be tempted to change this to "other software projects", prior art can come from almost anywhere

[nnullcolumn]

re: languages -> projects(?)