Support different encodings and decodings

[ghost]

Different operating systems and computers may use different textual encodings, thus, in order to operate on them, the file must be properly decoded.

Furthermore, it may be beneficial to allow the user to export a file using a different encoding.

This PR simply provides the user with an option to change the encoding that the whole application uses, defaulting to UTF-8.

All files are read and written to their file-system with the chosen encoding, whether it be correct or incorrect.

No speculative guesses are made by analyzing the user's text, they have to decide what they want to use on their own.

The user's choice should be saved upon reloading the application (via idb-keyval).

Suggestions, edits, and reviews are appreciated!

[google-cla[bot]]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

:memo: Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[ghost]

Currently, it just reads using the encoding, it does not write properly; this may be unexpected and harmful to the end-user.

Secondly, the way that they choose the encoding needs to be replaced entirely, suggestions?

[ghost]

@googlebot I signed it!

[ghost]

Oops, keyboard shortcuts for "Edit" and "Encoding" conflict with each other...

[ghost]

@petele If I might ask, is there any particular reason to prefer the current setup, consisting of divs, buttons, and JavaScript-controlled clicking and arrowkey functionality,

<div role="menu" class="menuItemContainer">
    <button ...>...</button>

over HTML select and option elements?

<select role="menu" class="menuItemContainer">
    <option ...>...</option>

or, say checkboxes/radios buttons?

<select role="menu" class="menuItemContainer">
    <input id="butWordWrap" type="checkbox">
    <label for="id="butWordWrap"">Word Wrap</labe.>

When adding a lot of buttons, the button list overflows, whereas the browser should prevent the latter two from overflowing, while choosing when to allow scrolling.

I'm finding that there are quite a few changes that would be necessary to accompany just changing one list to use this alternative, as some of the scripting, ex: the myMenus.hideAll listener acts up when targeting this, but it would be entirely unnecessary if using a native approach instead.

The DOM and scripts can easily be modified to use this alternative, but I'm asking because I believe that there may be something that I am not seeing, that you had possibly already anticipated?

Is there anything that would be harder when using this? Anything from your personal experience(s) that would make you prefer one over the other. Are there any cross-browser compatibility issues with this approach?

[ghost]

Oh, right, I remember why I never finished this, it wasn't possible.