Entry heads should preserve ý when present

[fbanados]

Currently, crk-db, lang-crk, and morphodict disregard ý characters in entries. We want to restore the original entries that had ý characters, but allowing the flexibility to restore the current behaviour (ý -> y) as an option for users.

This issue depends on UAlbertaALTLab/crk-db#115, once the FSTs are fixed, we can separately implement in morphodict a presentation option toggle to either show ý or y.

[fbanados]

Implemented draft behaviour in dev:

[fbanados]

Noticed a small bug in that the default selection does not appear highlighted, so it's hard to know what the presentation is until you click on an orthography. This should be changed to always show the current orthography highlighted.

[fbanados]

Also the current implementation of the unified frontend makes it impossible to have distinct orthographies in each deployment, that means that, although unused, the javascript code must be aware of all orthographies in all languages. Thus inclusion of new orthographies that have new codes requires both modifying the settings.py for a particular sssttt deployment, and the frontend.js list of options. It should be the case that only one place is required. Simplest change would be to autogenerate part of the javascript file in python by collecting all possible orthographies from every language. Then the introduction of a new orthography is isolated in the code.

This would be a stepping stone towards three refactoring options:

1. That each sssttt deployment can have their own individual frontend options (e.g. css options and corresponding javascript to implement frontend behaviour)
2. Orthographical changes that can be easily encoded in character mappings or javascript libraries and do not require an FST (currently, all of them) are computed at the client side instead of the server side. Biggest benefit of this approach could be to reduce the size of http requests.
3. That orthographies become a linguist-guided design option that does not require any coding: A configuration file could be used to autogenerate the parts of the frontend (and backend, depending on whether refactoring 2 is deployed) that are required to present multiple orthographies.