unify AJAX calls via AJAXController and add language parameter to all AJAX calls

[roewenstrunk]

This PR is related to #185 and #186

closes #186

[bwbohl]

Can #104 also be considered fixed with this PR?

[bwbohl]

After that is fixed it still fails, when tryinig to getPreference as long as the preferences aren't available yet.

This might fix it:

    getPreference: function (key, lax) {
        var me = this;

        (async () => {
            console.log("waiting for preferences");
            while (me.preferences === undefined) // define the condition as you like
            await new Promise(resolve => setTimeout(resolve, 1000));
            console.log("preferences defined");
            if (! me.preferences[key] && lax) {
                return null;
            }
            if (key == 'application_language') {
                var lang = me.getURLParameter('lang');
                if (lang) {
                    return lang;
                } else {
                    return 'en';
                }
            }
            if (me.preferences[key] == '' && key == 'image_prefix') {
                return '';
            }
            if (! me.preferences[key]) {
                Ext.Error.raise({
                    msg: 'No preference found with this key', key: key, level: 'warn'
                });
                return null;
            }
            return me.preferences[key];
        })();
    }

[bwbohl]

After that the language problem kicks in for getLanguageString…

so maybe we should test with a merged #308 ?

[bwbohl]

pinging @roewenstrunk

[bwbohl]

pinging @roewenstrunk

[bwbohl]

Attempt to boil it down to some understandable language:

1. When Edirom-Online loads without any further parameter in the call, it does not know the active edition and thus does not know where to find the edition preferences.

2. The AJAXController has an override variable that comes from the old plugin mechanism. The idea was that for any JS or XQuery file in the Edirom-Online code a custom file could be injected by defining the file path of the replaced file as preference @key and supplying the path to the injected file as value, e.g.:

   <entry key="plugin_annotView" value="../../../exist/rest/db/$CONTENTS_FOLDER$/$EDITION_ID$/$ANY_PATH$/$FILE_NAME$.js"/>

   3. This results in a check for a 'plugin' when trying to load the preferences, which cannot succeed because the definition of a plugin would be in the preferences and of course injecting another preferences file this way would be complete nonsense.

Theoretically, possible solutions could be to:

1. Avoid override check when fetching preferences
2. Catching an error on the override variable when trying to fetch an override defined in the preferences fails
3. getting rid of the Plug-In mechanism which actually isn't state of the art – relying on rest – and might pose major security concerns.