Ensure list of translatable languages is available early in bootstrap

This is an alternate patch for #1998088: Convert locale_translate_english variable to CMI
And part of #1775842: [meta] Convert all variables to state and/or config systems

Patch description

Instead of just adding a setting for 'locale_translate_english' we keep a list of translatable languages in config('locale.languages') which will allow us to get the full list of 'locale translatable languages' from configuration and looks like this:

# Example for English not translatable, Spanish translatable.
en:0
es:1

The reasons

The reasons, copied from https://drupal.org/node/1998088#comment-7693353
- Other locale components do need the full list of translatable languages injected into DIC somehow. Right now the only way of having it without having a dependency on locale module fully loaded is duplicating the code. See the patch here #1966538: Translation is not updated for configuration, when the config changes

+class LocaleConfigManager {
+
............................
+  /**
+   * Returns list of translatable languages.
+   *
+   * @return array
+   *   Array of installed languages keyed by language name. English is omitted
+   *   unless it is marked as translatable.
+   */
+  public static function getTranslatableLanguages() {
+    $languages = language_list();
+    if (!variable_get('locale_translate_english', FALSE)) {
+      unset($languages['en']);
+    }
+    return $languages;
+  }
+
}

- Since we have that 'locale_translatable_language_list' the fact that LocaleTranslation or LocaleConfigSubscriber don't use that list is an API consistency issue.

Explaining current dependency issues

When locale module is enabled, since the Locale components are loaded into the compiled DIC, configuration events may trigger LocaleConfigSubscriber events, which most likely will have a dependency on locale_translatable_language_list(). There are chances though, that these configuration events are triggered before the locale module is loaded.
Atm we are blindly loading language configuration overrides -or attempting to- for all languages, also for those that are not translatable. This 'problem' goes unnoticed for now because it only relies on such configuration overrides existing, though it is certainly a waste of resources. But it cannot be ignored when configuration updates trigger complex translation update events, like searching for translatable strings inside the configuration.
This applies too to the LocaleTranslation component, that is used from t() and right now cannot check whether the requested translation is for a 'translatable language' (other than English for which a variable is used). This is ok atm because all the configured languages -with the exception of English- are meant to be always translatable but will prevent future usage of the configured language list for other purposes that do not require interface translation.

So I think this issue would be a good chance to fix this variable in a really useful and more generic way. Though not an API addition by itself, it should allow contributed modules to further tweak the list of translatable languages and make it different from the list of content languages.