Normative: Remove implementation-defined behavior for Number methods

[littledan]

Number.prototype.toFixed, toExponential and toPrecision previously
permitted a second argument, with implementation-defined behavior.
This language dates back to the original specification in ES3.
However, in testing with eshost and looking at the sources of V8,
SpiderMonkey, JSC and ChakraCore, I cannot find a usage of this
second argument.

This patch removes the implementation-defined behavior clause to
simplify spec reading and reduce a potential point of variability
and confusion among new implementations.

[rwaldron]

This gained consensus on March 22nd

[littledan]

I don't think it's possible to write tests for this change.

Tangent: Once something has consensus, why not just write the label as "has consensus"--the awaiting merge part should be implicit, if the other appropriate conditions are met.

[ljharb]

Sounds good; removed the tests label. My thinking was that it'd be more of an explicit call-to-action for @bterlson as he scans the PR list; I don't think it's important either way if the label has the CTA or not.

[leobalter]

"has consensus" => "hey, Brian, please merge this" or just "Brian..."

both forms (short or long) works for me. As long we have a label, it's an explicit status after consensus is achieved.

[bakkot]

"has consensus" might not mean "can be merged" if we're still getting tests ready, strictly speaking.

[bterlson]

@bakkot I do not wait for tests to merge typically. Sorry for missing this PR.