[RFR] I18n provider new signature

[fzaninotto]

In order to allow different translation frameworks than Polyglot (#2307), or to pass options to the Polyglot constructor (#3662, #758, #366), we need to move some react-admin logic inside the i18nProvider.

With this PR, the i18nProvider has a signature similar to the other providers: it accepts a message type (either I18N_TRANSLATE or I18N_CHANGE_LOCALE) and a params argument.

// react-admin 2.x
const i18nProvider = (locale) => messages[locale];

// react-admin 3.x
const i18nProvider = (type, params) => {
    const polyglot = new Polyglot({ locale: 'en', phrases: messages.en });
    let translate = polyglot.t.bind(polyglot);
    if (type === 'I18N_TRANSLATE') {
        const { key, options } = params;
        return translate(key, options);
    }
    if type === 'I18N_CHANGE_LOCALE') {
        const newLocale = params;
        return new Promise((resolve, reject) => {
            // load new messages and update the translate function
        })
    }
} 

But don't worry: react-admin v3 exports a function called polyglotI18nProvider, that you can just wrap around your old i18nProvider to make it compatible with the new provider signature:

import React from 'react';
-import { Admin, Resource } from 'react-admin';
+import { Admin, Resource, polyglotI18nProvider } from 'react-admin';
import englishMessages from 'ra-language-english';
import frenchMessages from 'ra-language-french';

const messages = {
    fr: frenchMessages,
    en: englishMessages,
};
const i18nProvider = locale => messages[locale];

const App = () => (
-   <Admin locale="en" i18nProvider={i18nProvider}>
+   <Admin locale="en" i18nProvider={polyglotI18nProvider(i18nProvider)}>
        ...
    </Admin>
);

export default App;

[djhi]

While we are at it, why not extracting the default i18nProvider using polyglot in its own package ? People implementing it with another library will not need this dependency