Normative: Require at least four digits in string representations of negative years

[gibson042]

Fixes #1035

[littledan]

Spec text looks good to me. FWIW, it seems like ChakraCore and SpiderMonkey currently ship these semantics.

[gibson042]

Tests: tc39/test262#2114

[gibson042]

XS (and only XS) seems to always format negative years with six digits: https://circleci.com/gh/tc39/test262/340?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link#action-107

This is interesting because that behavior is required of Date.prototype.toISOString for conformance with ISO 8601, but toDateString/toUTCString/etc. have no such requirement. It superficially makes sense here, but gets trickier when we remember ISO also requires a plus sign for representing years after 9999. In other words, the same conformance with ISO 8601 that motivates use of six digits to represent every negative year from those methods would also motivate use of a plus sign and six digits to represent large positive years.

I personally foresee more problems than benefits stemming from e.g. "Mon, 01 Jul +065535 10:23:42 GMT", so I'm inclined to keep the tests as they are (requiring the minimum number of digits greater than or equal to 4, with no tainting from ISO 8601 year expansion).

[gibson042]

Update: I have introduced a StringPad operation as suggested above by @ljharb, for precisely defining the representation of negative years in a way that prohibits e.g. "-001234" (as undesirably exhibited by XS).

[ljharb]

@gibson042 5e0b005 seems editorial to me, and something i'd love to land separately/first. Would you be willing to make a separate PR for that commit? (you can leave it here, ofc, it will rebase out after the other one lands)