Streamline more error cases around month code parsing

[sffc]

#7010

This adds ValidMonthCode as an internal type.

Suggested in #7100

[Manishearth]

I don't really want us to switch to a new month code everywhere. When I mentioned ValidMonthCode I was narrowly mentioning it as a potential unstable API for ecma_reference_year.

In the medium term we can consider migrating.

[sffc]

I made the type fully internal.

For now I'm passing tuples into the Rules traits. We should revisit whether to export ValidMonthCode when we graduate the Rules traits in 2.2.

[Manishearth]

I like this

[sffc]

I'll wait on @robertbastian since he usually has feedback on errors.

autosubmit = true

[sffc]

Note: this PR changes EcmaReferenceYearError (which is internal) to have 2 variants instead of 3 variants. I did try putting it down to 1 variant via Option<Result>, but it made the implementers and call sites substantially more complex in my opinion, so I reverted to keeping 2 variants in the error enum. We could revisit this for the public Rules traits upon graduating them.

[sffc]

This PR is not merged yet but might conflict with #7115 and #7104. Whoever starts work on those PRs should merge this first.

[Manishearth]

@sffc #7115 does not conflict, I already checked locally.

#7116 (the other half of #7104) is built on top of this PR.