Default no longer needs to be a property on Language or ConfigurableLanguage

1. +++ b/core/modules/basic_auth/src/Tests/Authentication/BasicAuthTest.php
   @@ -119,7 +119,8 @@ function testPerUserLoginFloodControl() {
   -    ConfigurableLanguage::create(array('id' => 'de', 'label' => 'German', 'default' => TRUE))->save();
   +    ConfigurableLanguage::createFromLangcode('de')->save();
   +    \Drupal::config('system.site')->set('langcode', 'de')->save();
   

   So the prior approach to set the site default language ensured that you can only set a default language for a valid language.

   We need some ensurance that the site default language exists as a language on the site, so you cannot just set 'yy' as the default language and move on :)

   If this is done on the config directly and not eg. a method on the language manager or the default language service which could check if the value is valid, then bad things may happen. Yeah I know still you could use the config API at the end, but if our default API is the config API, then it can go wrong in itself, no?

2. +++ b/core/modules/language/src/Entity/ConfigurableLanguage.php
   @@ -186,26 +153,6 @@ public function postSave(EntityStorageInterface $storage, $update = TRUE) {
      /**
   -   * Converts the ConfigurableLanguage entity to a Core Language value object.
   -   *
   -   * @todo fix return type hint after https://drupal.org/node/2246665 and
   -   *   https://drupal.org/node/2246679.
   -   *
   -   * @return \Drupal\Core\Language\LanguageInterface
   -   *   The language configuration entity expressed as a Language value object.
   -   */
   -  protected function toLanguageObject() {
   -    return new LanguageObject(array(
   -      'id' => $this->id(),
   -      'name' => $this->label(),
   -      'direction' => $this->direction,
   -      'weight' => $this->weight,
   -      'locked' => $this->locked,
   -      'default' => $this->default,
   -    ));
   -  }
   -
   

   Yay for being able to remove this :)

I had a long IRC discussion with @alexpott about the pre-patch state encouraging you to have a language to set it default, ie. $language->set('default', TRUE); which "ensured" you had that language, while it is totally possible to set arbitrary language codes with the other API that is encouraged / spread by this patch, as in $config->set('langcode', $somelangcode); While it is true pre-patch we could have used the later API as well, post patch we can only use the later API.

I don't agree it is on the same level of fault tolerance merely for now having only the more free-form way to set a default language, but we did not agree with @alexpott and I don't care enough to argue about this more. His point in short is one could argue to that to set a language as default you should get the language from the language manager and set the system.site:langcode from that (direct quote).

So then this is as good as it will get. I agree with the other changes and that default is external to the language not internal, it is a system property rather a language property.

read through this. tiny nit (missing space to indent a line).
also added the one line descriptions on properties and the @params. (I agree that in cases like this, it is repetitive and a bit silly, but... well, we dont say "unless it is sillily repetitive in our standard. so...)

Should still be rtbc.

opened #2340517: add a method to ConfigurableLangaugeManagerInterface to set the default language [edit: took out a misunderstanding of mine.]

+++ b/core/modules/language/src/EventSubscriber/ConfigSubscriber.php
@@ -20,18 +20,26 @@
+   * The language Manager.

Wrong capitalization

:)

Back to RTBC then.

opps. sorry. the interdiff was right, but the patch not.
This should be better.

Always found this annoying. When you have a property on something that's mutually exclusive with other items in the set something is wrong.

Committed/pushed to 8.0.x, thanks!

Thanks a lot!