Editorial: Refactor ResolveLocale to simplify calls

[gibson042]

This has been bugging me for quite a while.

• Rename dataLocaleData aliases to the more accurate resolvedLocaleData
• Update the return value to include locale data rather than its lookup key
• Capitalize the return value static field names

[ben-allen]

I am entirely for this change -- I've found the name _dataLocaleData_ to be borderline unreadable -- though I'm concerned that others might dislike losing the relationship between the name of the alias and the name of the [[DataLocale]] slot. @ryzokuken @sffc @FrankYFTang

[sffc]

The word "resolved" to me means that the data went through some resolution algorithm, which I guess it did because of dataLocale. I think better would be to rename the variables to "resolvedLocale" and "resolvedLocaleData". But I don't have a strong preference.

[anba]

I wonder if we could remove the term "dataLocale" from the spec. I've created #853 as a possible alternative to this PR.

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2024-02-22.md#editorial-rename-datalocaledata-aliases-to-the-more-accurate-resolvedlocaledata-849

[gibson042]

@ben-allen @ryzokuken This has extended to change the shape of the ResolveLocale return value and refactor an internal slot of NumberFormat and RelativeTimeFormat instances, so I'm requesting re-review before merging.