settings: Add migration for `state.settings.{locale -> language}.

Looks like this got lost in zulip#4901.

As Greg points out [1]:

> I think this means a regression in the current beta: on upgrade,
> we'll effectively forget the user's choice of language, and revert
> to the default of English.

> The fix should be pretty simple: just add the missing migration.
>
> For non-beta users, it'll be as if it was never broken.
>
> For beta users who upgraded to version 166 or 167, and then
> upgrade to a version with that fix, the effect will be that we
> take the setting they had before the 166 or 167 upgrade, and
> revert to that setting. For most of them that will either have no
> effect (because they already went and changed the setting back to
> the same preferred language), or take them back from English to
> the language they want to be using… or both (because their
> preferred language was English all along). There's a possibility
> that some users will have made a different choice since the
> upgrade, and this will clobber that choice. That seems fine; it's
> a pretty tolerable glitch for using beta releases of software, and
> any other solution would be more complex.

[1] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/state.2Esettings.2Elanguage/near/1246410

src/boot/store.js

@@ -321,6 +321,19 @@ const migrations: {| [string]: (GlobalState) => GlobalState |} = {
     },
   }),
 
+  // Rename to `state.settings.language` from `state.settings.locale`.
+  '31': state => {
+    // $FlowIgnore[prop-missing]: migration fudge
+    const { locale: language, ...settingsRest } = state.settings;
+    return {
+      ...state,
+      settings: {
+        ...settingsRest,
+        language,
+      },
+    };
+  },
+
   // TIP: When adding a migration, consider just using `dropCache`.
 };