Spell out RFC considerations for library functions more explicitly (#603)

When considering new standard library functions, we essentially need to strongly justify their existence over their implementation in Luau in user library code.

This PR attempts to provide a few axes of consideration; ideally new library functions tick many of the boxes, eg "used often + is more performant + clear unambiguous interface" is an ideal consideration for a library function, whereas if it's merely accelerating a single specific use case for a single application it's unlikely to be a good justification for inclusion.

rfcs/README.md

@@ -18,6 +18,13 @@ For changes in semantics, we should be asking:
 - Can it be sandboxed assuming malicious usage?
 - Is it compatible with type checking and other forms of static analysis?
 
+For new standard library functions, we should be asking:
+
+- Is the new functionality used/useful often enough in existing code?
+- Does the standard library implementation carry important performance benefits that can't be achieved in user code?
+- Is the behavior general and unambiguous, as opposed to solving a problem / providing an interface that's too specific?
+- Is the function interface amenable to type checking / linting?
+
 In addition to these questions, we also need to consider that every addition carries a cost, and too many features will result in a language that is harder to learn, harder to implement and ensure consistent implementation quality throughout, slower, etc. In addition, any language is greater than the sum of its parts and features often have non-intuitive interactions with each other.
 
 Since reversing these decisions is incredibly costly and can be impossible due to backwards compatibility implications, all user facing changes to Luau language and core libraries must go through an RFC process.