refactor(locale)!: remove location data index-value-binding

[xDivisionByZerox]

Removes the requirement for direction locale data lists to be sorted in a specific order.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.95%. Comparing base (734a7f3) to head (d4ed4f5).

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #2476      +/-   ##
==========================================
- Coverage   99.96%   99.95%   -0.01%     
==========================================
  Files        2971     2966       -5     
  Lines      212620   212579      -41     
  Branches      597      950     +353     
==========================================
- Hits       212546   212490      -56     
- Misses         74       89      +15     

Files	Coverage Δ
src/locales/da/location/direction.ts	100.00% <100.00%> (ø)
src/locales/da/location/index.ts	100.00% <ø> (ø)
src/locales/en/location/direction.ts	100.00% <100.00%> (ø)
src/locales/en/location/index.ts	100.00% <ø> (ø)
src/locales/eo/location/direction.ts	100.00% <100.00%> (ø)
src/locales/eo/location/index.ts	100.00% <ø> (ø)
src/locales/fa/location/direction.ts	100.00% <100.00%> (ø)
src/locales/fr/location/direction.ts	100.00% <100.00%> (ø)
src/locales/fr_CH/location/direction.ts	100.00% <100.00%> (ø)
src/locales/he/location/direction.ts	100.00% <100.00%> (ø)
... and 9 more

... and 1 file with indirect coverage changes

[ST-DDT]

Looks good to me.
Not sure whether we should push this in v8 or v9.

[ST-DDT]

Since we change the layout of our locale data, I think we should merge this in v9.0.

[ST-DDT]

I checked that no new files have been added in the meantime.

[Shinigami92]

docs/guide/upgrading_v9/2476.md file required

[xDivisionByZerox]

Looking at #2505, would it make sense to "flatten" this definitions as well? So instead of direction object with nested properties, we'd have 4 files/4properties on the location definition object.

[ST-DDT]

Looking at #2505, would it make sense to "flatten" this definitions as well? So instead of direction object with nested properties, we'd have 4 files/4properties on the location definition object.

We could do that, but these files are so small, that it would be harder to review the files if split up.
IMO we keep them in a single file.

[netlify]

✅ Deploy Preview for fakerjs ready!

Name	Link
🔨 Latest commit	d4ed4f5
🔍 Latest deploy log	https://app.netlify.com/sites/fakerjs/deploys/661c55b5d613c40008908b8f
😎 Deploy Preview	https://deploy-preview-2476.fakerjs.dev
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[xDivisionByZerox]

I put "needs decision" as I'd like to discuss my last comment in the next team meeting.

[ST-DDT]

Team Decision

We will not flatten the definitions in the same way as #2505 .

Reason:

• Being a nested object ensures that all values are always present, as the type requires it. On the other hand entries in categories are optional by force and thus it might lead to cases where abbr is set but the full value is missing.