<!--  As an open source project with a dedicated but small maintainer team, it can sometimes take a long time for issues to be addressed so please be patient and we will get back to you as soon as we can.
-->

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

### Problem Description
<!-- Is your feature request related to a problem? Please add a clear and concise description of what the problem is. -->

Under a Windows machine using English as a display language, Japanese kanji texts are rendered with Chinese font `SimSum`. This behavior matches with Chrome's one if the machine doesn't list Japanese as an alternative preferred locale, and HTML content language is set to `en-US`.
But if the machine lists Japanese as an alternative, Electron should render the text with Japanese fonts.

AFAIK, Chrome renders kanji texts (Han script) with Japanese fonts when the accept-language configuration includes Japanese, as reading Chromium (blink)'s [font_fallback_win.cc](https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/win/font_fallback_win.cc). This behavior is done by considering the system locales including secondary/alternative locales. Because of this, I don't encounter the same problem in Chrome.

Looks like Electron currently honors only primary system locale and content locale (HTML `lang`), but not secondary/alternative locales. Thus I think Electron's current behavior is not following Chrome's one.

As I'm not familiar with the Electron codebase, I'm still not sure why the current implementation doesn't make this problem on Mac. I'm listing Japanese as an alternative locale both on my Mac and Windows machine, but this problem happens only on Windows; as looking into font related codes in Chromium, I guess macOS' CoreText is doing good for choosing a font.

Related to #15486 #18197.

In real life, for Slack workspace/Discord servers where its primary language is Japanese, this problem forces people using English as a primary system language to read Japanese with an unmatched font, which is rendered ugly as a Japanese text. I don't think letting app developers using Electron to implement font configuration is happy, just for this problem. Electron should provide a good default to devs.

### Proposed Solution
<!-- Describe the solution you'd like in a clear and concise manner -->

Get _all_ preferred locales from OS and set them to Chromium engine. I'm guessing https://github.com/electron/electron/pull/15532 fixes this problem.

### Additional Information
<!-- Add any other context about the problem here. -->

#### Japanese text shown on Slack app (Windows)

![Japanese text](https://img.sorah.jp/x/20190616_130936_PbjXWPa70A.png)

If I manually change `<html>` lang to `ja-JP`, kanji text starts rendered with Japanese font, Meiryo.

#### Windows Language Preference

![English, Japanese](https://img.sorah.jp/x/20190616_130723_KbBw6nUXLK.png)

#### Mac Language Preference

![English, Japanese](https://img.sorah.jp/x/20190616_131026_DagQq3fgNc.png)

shell/browser/api/electron_api_web_contents.cc
bool only_dirty = false;
  FrameSubscriber::FrameCaptureCallback callback;
  args->GetNext(&only_dirty);
  if (!args->GetNext(&callback)) {
    args->ThrowError();
    return;
  }
  frame_subscriber_ =
      std::make_unique<FrameSubscriber>(ontents(), callback, only_dirty);
}
void Ws::EndFrameSubscription() {