refactor: change `location.state` to return an object with formal state name, common name, abbreviation

[ejcheng]

Per internal team decision, we've decided to change location.state to return an object for each state with the state's full formal name, common name, and abbreviation. This change will be targeted for v9.

How should we best implement it gradually? Should we first deprecate the abbreviated boolean parameter on location.state?

Blocked by #1850

[matthewmayer]

What if there was a new parameter like {object:true} to return the object instead of a string. Then it wouldn't be breaking.

[matthewmayer]

(or a new method like faker.location.stateObject())

Might be worth the slightly more awkward naming to avoid breaking change on a very old & stable method.

[ST-DDT]

Team Decision

We will change location.state() to return a complex object in v9.

[matthewmayer]

I think #1850 should be a prerequisite for this, because i imagine there's a fair amount of existing code like

const address = faker.helpers.fake("{{location.city}}, {{location.state}}") and there won't be an easy migration path for that if you can't access location.state.commonName or whatever

[matthewmayer]

i'm still about dubious about changing the behavior of the existing methods. Sure, it will be in the migration guide, but people don't always read those, and subtle changes like this that don't issue deprecation warnings are easy to miss. You upgrade to v9, run your code, no warnings are shown, but then suddenly your location code starts outputting Detroit, [Object object] and you're not sure why. (ref #2288).