The previous behavior was to honor the mute switch to mute audio
played through web pages and video, so that a web page could never
play audio through the speakers unless you wanted it to by adjusting
the mute switch.

Since this behavior might be confusing to people (like the person
that left a 1-star review because the app didn't play sound), add an
option to disable this behavior and always play audio regardless of
the mute switch.

This makes it possible to have live search results for queries with
dots in them, but since this may be a URL (without a scheme) and
private, leave the default as it was before and stop searching when
the first dot is entered.

This same dialog is used for origin URL DNS lookup failures and
other errors.

[[NSURLComponents alloc] initWithString:] was previously getting
passed a nil URL in certain cases, when [NSURL URLWithString:newURL]
failed.

When viewDidLayoutSubviews is called during transition from keyboard
up to back down, self.view.safeAreaInsets.bottom is 0, which
viewDidLayoutSubviews uses to place the toolbar at the very bottom
of the screen.

Once the keyboard is actually down, viewSafeAreaInsetsDidChange is
then called slightly after which adjusts safeAreaInsets.bottom to
something bigger.

viewSafeAreaInsetsDidChange can't just call viewDidLayoutSubviews
though, because showingTabs is still true. So work around this by
caching any non-zero safeAreaInsets.bottom and use it when the
keyboard is still up but transitioning down (when it would be zero).

If the software keyboard is on-screen, the web view can't show
underneath it or else it won't be able to scroll down far enough to
show the bottom of the page.

This is especially problematic if there are text fields near the
bottom since you won't be able to see the input you're typing.

cmd+left and cmd+right are used in text entry, so use the same
shortcuts as Safari

Fixes #69

This enables TUSafariActivity to again work properly and return YES
from canPerformWithActivityItems:

A <form action="url/#anchor"> that ends up resulting in a 301
redirection to a URL without an anchor is supposed to go to the
final redirection with the #anchor preserved.

This seems to mirror behavior of other browsers.

Default to supporting any new ciphers with an id higher than the
newest one we currently support, assuming that any newly
standardized ciphers will be secure.

Implement activityViewController:subjectForActivityType: so when
sharing URLs in an app like Mail.app, the subject of the e-mail will
be the title of the web page, in addition to the URL in the body

I think I've made about $10 total off of this, and it costs me more
to keep the endl.es domain each year.

Fixes searching for "at&t" from url bar

Fixes #65

iOS 11.4 started sending additional UIKeyboardWillShowNotification
notifications when the user taps on the URL bar when the keyboard is
already up, so keyboardHeight ends up being 0 (because there is no
change in FrameBegin->FrameEnd) and disappears.

Keep track of whether the keyboard is showing and ignore these
duplicate events until we get a UIKeyboardWillHideNotification
event.

Videos in a UIWebView load through URLInterceptor with a different
User-Agent than normal requests, which means they do not carry the
per-tab hash we append in WebViewTab.

The UA for a normal request looks like this:
Mozilla/5.0 (iPhone; CPU iPhone OS 11_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Mobile/15E216 Safari/605.1.15/7853040736

The UA for a video request looks like this:
AppleCoreMedia/1.0.0.15E216 (iPhone; U; CPU OS 11_3 like Mac OS X; en_us)

Previously URLInterceptor would block these requests because the
hash could not be found in the UA, which meant that videos would not
load. We now allow AppleCoreMedia requests and assume they come
from the current tab.

I have no idea how this worked before because I've seen video on
some sites load, but URLInterceptor would have always been dropping
those requests.

In case this is causing issues, it can be disabled temporarily or
for a single host.

This may help the crashes reported in [HSTSCache writeToFile:]

The URL being redirected from may not have the rule apply, so pass
the URL being redirected to so it can also be checked.

Fixes redirection loop from https://planet.gnome.org/ to http://

Closes #56

titleForDeleteConfirmationButtonForRowAtIndexPath was not being
called to change swipe-to-delete buttons to Enable/Disable

It conforms to the same thing 1Password is doing and shows up in the
same share menu