webview: Tidy up style and comments for new handshake code.

This cleans up a few small things from the parent commit:
 * Pull the detailed handshake logic out of `componentDidMount`
   into its own method.
 * Rename `isWebViewReady` to be a bit more specific, and to
   have the grammar of a fact rather than a question, as in
   `if (isReady)` -> "if the thing is ready".
 * Keep mentions of the MessageInput* types in a consistent order.
 * Make the comments a lot terser.

See the parent commit for detailed explanation of this code.

android notif: Clean up redundancies in getNotificationBuilder.

android: Disable AAPT2 for now, to unblock release builds.

This became the default with Android Gradle Plugin version 3.0.0:
  https://developer.android.com/studio/releases/gradle-plugin#3-0-0
So turning it off returns us to the behavior before we recently
took that upgrade.

Without this line, we run into this issue when attempting to make a
release build:
  facebook/react-native#16906
That issue was closed long ago when an intended fix was merged, but
then that was reverted.  The fix went back in as da6a5e043 upstream,
which is in v0.57.0, so we'll get it when we take that upgrade;
hopefully that then fixes this for real.

webview: Better match the invoke-lightbox logic to the webapp.

When the user touches an image in the message list, we've been
deciding whether to invoke the lightbox for it based on whether its
parent element is a link with `target="_blank"`.  This is unsemantic
and kind of quirky, and in fact it doesn't always get the right
answer; for example, this was causing us to pull up a (failed,
blank) lightbox for the avatar in an embedded tweet, or for the
giant file-type icon in an embedded Dropbox link.

Instead, use the rather more semantically plausible test found in
the webapp.

Also add a few comments; explain in particular the "video" exceptions.

This code still isn't quite right, and the difference shows up in
the case of an embedded Dropbox *image*: we should be getting the
image URL from, well, the `img` element, but instead we're getting
it from the enclosing link, which has a different job and in the
case of a Dropbox image points to the `?dl=0` HTML page which
displays the image.  In that case, a lightbox is the right thing,
but because we use the wrong URL we show a blank one.  Leave that as
a TODO to be fixed separately, along with thumbnailing-awareness.

tools/bump-version: Add auto-commit.

The slick Bash feature with `${...@q}` that I use here for nicely
shell-quoting a value is one I just now learned when looking for
alternatives in the Bash manual.  I'd never seen it before; which
turns out to be because it's "only" two years old!

messages: Initialize new state subtrees in migrations.

Each migration should take a state that was a valid value of the old
`GlobalState` type, and return a state that is a valid value of the
new `GlobalState` type.

In particular, when we create a new state subtree (i.e. a new property
on `GlobalState`), the migration should initialize that subtree.

The reason we've largely gotten away without doing this (we've had no
migrations at all until recently, so certainly haven't been doing
this) is that only a small amount of code is exposed to any failure
here -- only REHYDRATE handlers, when handling the `payload` of the
action -- because the actual Redux state is always initialized in the
standard Redux way, by invoking the handlers with `undefined` previous
state.  In cases where this is complicated to do, we might choose to
skip it in the future too.

But here we have an actual, critical, bug that this prevents.  When
starting up the app, with a state left behind by a version from before
these migrations, we never get past the green loading screen; and the
log shows `TypeError: Object.values called on non-object` inside a
function named `rehydrate`, which must be the one in `flagsReducers`.
That's because `action.payload` has no property `messages` -- contrary
to our type annotation saying a REHYDRATE action's payload should be a
`GlobalState`.

And fixing it once and for all in these migrations (rather than worry
about future bugs if future changes we make to rehydrate code
innocently make this same assumption) is easy.  So do that.

ios: Remove support for iOS 8, make 9 the minimum

Updates the minimal iOS platform version supported up from
8.2 to 9.

This makes it official and the app will not be available for
download on iOS 8 devices. Our app currently crashes/exits on
startup without any reported error to Sentry or iTunes Connect.
This was verified both on a physical device and BrowserStack's
App Live.

We are not limiting our device support as all devices that run
iOS 8 can be upgraded to 9.

More information about devices and platform support:
http://iossupportmatrix.com/
https://everyi.com/by-capability/maximum-supported-ios-version-for-ipod-iphone-ipad.html

android notif: Ignore GCM messages we don't understand.

The GCM messages sent by the Zulip server use the key `event`
(think "event type") to identify the type of the message.  In all
current versions of the Zulip server, the only value for `event` is
`message`, meaning the GCM message is describing a Zulip message
which the app should notify the user about.

If we get a GCM message with some other event type, then we can't
possibly interpret it sensibly.  If we try to do so, then it's
impossible to introduce new features requiring new event types
until all users have updated the app to a version new enough to
know about them, because older versions are likely to produce
gobbledygook to show to the user.

For example, server commit bc43eefbf, which will be in Zulip
Server 1.9 but with its behavior disabled by a setting, introduces
an event type of `remove` -- meaning the GCM message is about a
Zulip message which the user has now read, and we should *remove*
from any notifications display.

So, ignore such things.  The user simply won't get the benefit of
the new feature until they upgrade, like other new features.

webview: Encode input messages in base64.

Fixes zulip#2505, zulip#2538, zulip#2558.

When using `postMessage` to communicate with the WebView, depending
on the content of the message we send, an exception might be thrown.

A minimal but reliable way to reproduce the issue is to send the
string `'%22'`.  Other character combinations might also cause issues.

To work around the issue, we encode our data in the nice boring
characters of base64 so that it doesn't get reinterpreted.

---

More details on how React Native sends messages to the WebView:

The logic is different on iOS vs. Android.  This explains why the
issue this is fixing is Android-specific.

On iOS, a custom navigation scheme is used to pass the data into the
webview; search the RN source for `RCTJSNavigationScheme`, and see the
implementation of `webViewDidFinishLoad` in `RTCWebView.m`.

The Android messaging happens in `receiveCommand` in
`ReactWebViewManager.java`, by navigating to a URL of the form
`javascript:(.....)`, which is a standard way of injecting JavaScript
into web pages.

The issue comes from the fact that since Android 4.4, `loadUrl` does
a URL decode on the string passed to it:
  https://issuetracker.google.com/issues/36995865

See zulip#2854 for links to upstream RN bug reports and PRs.

[greg: lightly revised commit message; found better reference for the
 `loadUrl` issue]

settings: Add margin between account buttons and option buttons.

This is a minor visual polish.